Data Object Based Application State Sharing Methods for User Devices

ABSTRACT

A method of sharing a state of an application by a first user device to a second user device is provided. The method includes: receiving at a processor of the first user device a user input to share the state, where the application is executed on the processor at the first user device; in response to the user input, generating share and destination requests selecting a share method and a destination link based on responses to the share and destination requests; determining app state information corresponding to the state; and generating via the processor a data object based on the app state information. The method further includes transmitting the data object from the processor to a sharing server or a second user device based on the share method and the destination link, wherein the transmitting of the data object shares the state with the second user device.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims the benefit of U.S. ProvisionalApplication No. 62/272,264, filed on Dec. 29, 2015 and U.S. ProvisionalApplication No. 62/272,282, filed on Dec. 29, 2015. The entiredisclosures of the applications referenced above are incorporated hereinby reference.

FIELD

This disclosure relates to sharing states of applications.

BACKGROUND

The number of available software applications (referred to herein as“Apps”) has grown for user devices, such as computers, smartphones,mobile devices, televisions, in-vehicle computers, and otherInternet-connected devices. Many diverse native and web-based softwareapplications are available and can be accessed by the user devices. Theapplications include business related applications, game applications,educational applications, news applications, shopping applications,messaging applications, media streaming applications, social networkingapplications, etc. Application developers develop vast amounts ofapplications within each genre and each application may have numerouseditions.

Applications are used to accomplish specific functions and/or tasks.Applications have corresponding application states, which are used toaccomplish each task and/or function. As an example, the applicationstates can refer to windows and/or a set of display objects presented toa user to allow the user to accomplish and/or request performance ofcertain tasks and/or functions. As the number of applications, thecomplexity of the applications, and/or complexity of correspondingwebsites increases, it becomes ever more difficult to identify a correctapplication and/or application state to accomplish a given task and/orfunction.

SUMMARY

A method of sharing a state of an application from a first user deviceto a second user device is provided. The method includes: receiving at aprocessor of the first user device a user input to share the state ofthe application, where the application is executed on the processor atthe first user device; in response to the user input, generating a sharerequest and a destination request; selecting a share method and adestination link based on responses to the share request and thedestination request; determining app state information corresponding tothe state of the application; and generating via the processor a firstdata object based on the app state information. The method furtherincludes transmitting the first data object from the processor to asharing server or the second user device based on the share method andthe destination link, wherein the transmitting of the first data objectshares the state of the application with the second user device.

In other features, a method is provided and includes: receiving arequest from a first user device at a processor of a sharing server fora card record or app information, where the card record and the appinformation corresponds to a state of an application executed at thefirst user device, and where the request includes an application cardidentifier; and accessing card record information for the card recordand based on the application card identifier, where the card recordinformation comprises application state information, a templateidentifier, and access information, and where the card recordinformation has a reference to the application executed on the firstuser device and indicates an operation for a version of the applicationto enter the state. The method further includes: sending, in response tothe request, the card record information to the first user device;receiving a first data object based on the card record information;selecting a template based on the template identifier of the card recordor the first data object; populating the template with at least part ofthe application state information from the card record; and at least oneof transmitting the template to a second user device, or formatting thefirst data object to generate a second data object and transmitting thesecond data object from the sharing server to a second user device.

In other features, a method of rendering app state data, correspondingto an app executed at a first user device, at a second user device isprovided. The method includes: receiving at a processor of the seconduser device, a first data object from the first user device, where thefirst data object represents a state of the app executed on the firstuser device, and where the first data object comprises an applicationcard identifier; and determining whether to modify the first dataobject. The method further includes, if the first data object is notmodified, requesting a first template for the first data object from asharing server, and displaying, based on information in the first dataobject and the first template, the state of the app, a first cardcorresponding to the state of the app, or app information correspondingto the state of the app. The method further includes, if the first dataobject is modified: transmitting the first data object to a sharingserver; receiving a second data object from the sharing server, wherethe second data object is a formatted version of the first data object;receiving a second template for the second data object from the sharingserver; and displaying, based on information in the second data objectand the second template, a state of a second version of the app, asecond card corresponding to the state of the second version of the app,or app information corresponding to the state of the second version ofthe app.

In other features, a method of sharing a state of an application or acard from a first user device to a second user device is provided. Thecard is representative of the state of the application. The methodincludes: receiving, at a processor of the first user device, a userinput to share the state of the application or the card, where theapplication is executed on the processor at the first user device; inresponse to the user input, determining app state information via theprocessor; generating a data object representative of the state of theapplication or the card based on the app state information; generating ashare request and a destination request; selecting a share method and adestination link based on responses to the share request and thedestination request; formatting the data object to generate one or moremessages; and transmitting the one or more messages to the second userdevice based on the share method and the destination link, wherein thetransmitting of the one or more messages shares the state of theapplication or the card with the second user device.

In other features, a method of creating a card representative of a stateof an application executed on a first user device and shared with asecond user device is provided. The method includes: receiving ahypertext transfer protocol request from a second user device at asharing server, wherein the hypertext transfer protocol request includesa uniform resource locator; searching for a card record matching theuniform resource locator, a template for rendering the card, andconfiguration data; populating the template with data from the cardrecord and according to the configuration data; configuring a link forthe card; creating the card based on the template and associating thelink to the card; and transmitting the card to the second user device.

In other features, a method of rendering application state informationor a card, representative of a state of a first application executed ona first user device, at a second user device is provided. The methodincludes: receiving at a processor of a second user device a firstmessage including a uniform resource locator from a first user device,where the uniform resource locator specifying a server and the state ofthe first application executed at the first user device; receiving auser input indicating selection of a link for access information or theuniform resource locator; executing a second application that causes theprocessor to send a request to the server; receiving, from the server inresponse to the request and via the second application, code fordisplaying the card or the application state information extracted fromthe state of the first application; displaying, via the secondapplication, the card or the application state information correspondingto the link; selecting the card or the application state information;and launching, via the processor, the first application at the seconduser device based on the link, such that the first application executedat the second user device is in the state of the first application asexecuted on the first user device.

In other features, a method for sharing an application state isprovided. The method includes receiving, at a processor of a first userdevice associated with a first user, a data object from a second userdevice associated with a second user. The data object represents anapplication state of an application executable on the second userdevice. The data object includes a card record associated with theapplication state and application access information having a referenceto the application and indicating a performable operation for theapplication to enter an operating state providing information from thecard record. The method further includes displaying, by the processor, acard in a graphical user interface on a screen of the first user device.The card includes the information from the card record.

Implementations of the disclosure may include one or more of thefollowing optional features. In some implementations, when the cardincludes a user-selectable link associated with the application accessinformation, the method includes receiving, at the processor, a userselection of the user selectable link and executing, at the processor,the application access information associated with the selected userselectable link. The user selection may include at least one of a voicecommand, a touch gesture, or a click selection.

When the card includes a user selectable link associated with theapplication access information, the method may include receiving, at theprocessor, a user selection of the user selectable link, and displaying,at the processor, a representation of the application state of theapplication executable on the second user device without executing theapplication. The method may further include populating a card templatewith the information from the card record. The card template may bebased on at least one of a user device type of the first user device, anoperating system of the first user device, a data object type, or a usertype. The method may also include sending the data object from theprocessor of the first user device associated with the first user to athird user device associated with a third user. The data object mayinclude display configuration data.

Another aspect of the disclosure provides a user device for applicationstate sharing. The user device is associated with a first user andincludes a screen, a processor in communication with the screen, and amemory in communication with the processor. The memory storesinstructions that when executed on the processor cause the processor toperform operations. The operations include receiving a data object froma sharing device associated with a second user. The data objectrepresents an application state of an application executable on thesharing device. The data object includes a card record associated withthe application state and application access information having areference to the application and indicates a performable operation forthe application to enter an operating state providing information fromthe card record. The operations further include displaying a card in agraphical user interface on the screen. The card includes theinformation from the card record.

This aspect may include one or more of the following optional features.In some examples, the operations further include, when the card includesa user-selectable link associated with the application accessinformation, receiving a user selection of the user selectable link andexecuting the application access information associated with theselected user selectable link. The user selection may include at leastone of a voice command, a touch gesture, or a click selection.

When the card includes a user-selectable link associated with theapplication access information, the operations may include receiving auser selection of the user selectable link and displaying arepresentation of the application state of the application executable onthe sharing device without executing the application. The operations mayfurther include populating a card template with the information from thecard record. The card template may be based on at least one of a userdevice type of the first user device, an operating system of the firstuser device, a data object type, or a user type. The operations mayfurther include sending the data object to a receiving user deviceassociated with a third user. The data object may include displayconfiguration data.

Yet another aspect of the disclosure provides a second method forapplication state sharing. The method includes receiving, at a processorof a sharing server, a first data object from a first user deviceassociated with a first user. The first data object represents anapplication state of an application executable on the first user deviceand includes an identification of a second user device associated with asecond user. The method further includes determining, by the processor,a compatibility type of the second user device based on theidentification of the second user device and sending a second dataobject from the processor of the sharing server to the second userdevice. The second data object includes a card record associated withthe application state and application access information having areference to the application and indicating a performable operation forthe application to enter an operating state providing information fromthe card record. The application access information is formatted basedon the compatibility type of the second user device.

This aspect may include one or more of the following optional features.Determining the compatibility type of the second user device may includesearching a data source for compatibility information based on theidentification of the second user device. The data object may beformatted to be displayed as a card.

In some examples, the method includes populating a card template withthe information from the card record, the card template based on atleast one of a user device type of the first user device, an operatingsystem of the first user device, a data object type, or a user type. Themethod may further include sending the data object data from theprocessor to a third user device associated with a third user. The dataobject may include display configuration data.

Yet another aspect of the disclosure provides another method forapplication state sharing. The method includes receiving, at a firstuser device associated with a first user, a first data object from asecond user device associated with a second user. The first data objectrepresents an application state of an application executable on thesecond user device and includes a card record associated with theapplication state and application access information having a referenceto the application and indicating a performable operation for theapplication to enter an operating state providing information from thecard record. The method further includes sending the first data objectfrom the first user device to a sharing server. The sharing serverformats the first data object into a second data object compatible withthe first user device. The method also includes receiving, at the firstuser device, the second data from the sharing server and displaying, atfirst user device, a card in a graphical user interface on a screen ofthe first user device. The card includes the information from the cardrecord.

In some examples, when the card includes a user-selectable linkassociated with the application access information, the method includesreceiving a user selection of the user-selectable link and executing theapplication access information associated with the selected userselectable link. The user selection may include one of a voice command,touch gesture, or a click selection.

In some examples, when the card includes a user-selectable linkassociated with the application access information, the method includesreceiving a user selection of the user selectable link and displaying arepresentation of the application state of the application executable onthe second user device without executing the application. The method mayfurther include populating a card template with the information from thecard record, the card template based on at least one of a user devicetype of the first user device, an operating system of the first userdevice, a data object type, or a user type. The method may also includesending the data object from the first user device associated with thefirst user to a third user device associated with a third user. The dataobject may include display configuration data. The details of one ormore implementations of the disclosure are set forth in the accompanyingdrawings and the description below. Other aspects, features, andadvantages will be apparent from the description and drawings, and fromthe claims.

In other features, methods and systems are provided that includereceiving, at processor of a first user device associated with a firstuser, a first message including a uniform resource locator (URL) from asecond user device associated with a second user, the URL specifying aweb server and an application state of a first application executable atthe first user device. The processor receives a selection by the firstuser of the URL. The processor executes a second application that causesthe processor to send a request to the web server. In response to therequest, the second application receives, from the web server, code fordisplaying application state information extracted from the applicationstate. The code further includes a link for accessing the state of thefirst application. The second application displays the application stateinformation and the link. The first user selects the link and theprocessor launches the first application using the link such that thefirst application displays the application state.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a functional block diagram of an example of a sharing serverin accordance with an embodiment of the present disclosure.

FIG. 2 is a functional block diagram of an example of a portion of thesharing server illustrating a sharing server interacting with a userdevice and data storage devices in accordance with an embodiment of thepresent disclosure.

FIG. 3A illustrates an example of the user device and selection andconversion of user selectable links to data objects in accordance withan embodiment of the present disclosure.

FIG. 3B illustrates an example of a first user device sharing anapplication state displayed as a card on a second user device inaccordance with an embodiment of the present disclosure.

FIG. 3C illustrates another example of a first user device sharing anapplication state displayed as a card on a second user device inaccordance with an embodiment of the present disclosure.

FIG. 3D illustrates an example of a first user device sharing a firstapplication state to a second user device, which is displayed as asecond application state in accordance with an embodiment of the presentdisclosure.

FIG. 3E illustrates an example of user devices sharing a cardrepresenting an application state in accordance with an embodiment ofthe present disclosure.

FIG. 3F illustrates an example of a user device sharing an applicationstate in accordance with an embodiment of the present disclosure.

FIG. 3G illustrates an example of a user device accessing a cardrepresenting a shared application state in accordance with an embodimentof the present disclosure.

FIG. 4 illustrates an example of a card record in accordance with anembodiment of the present disclosure.

FIG. 5 is a functional block diagram of an example of a user device inaccordance with an embodiment of the present disclosure.

FIG. 6 is a functional block diagram of an example of a sharing serverin accordance with an embodiment of the present disclosure.

FIG. 7 is a perspective view of an example computing device configuredto execute methods disclosed herein.

FIG. 8 illustrates an example method of sharing an application state ata first user device with a second user device in accordance with anembodiment of the present disclosure.

FIG. 9 illustrates an example method of providing a card record, aformatted data object and a template from a sharing server to the firstuser device and the second user device during the methods of FIGS. 8 and10.

FIG. 10 illustrates an example method of modifying (or formatting) andrendering application state related data at the second user devicecorresponding to an application state shared during the method of FIG. 8by the first user device.

FIG. 11 illustrates an example method of sharing a card and/or anapplication state of a first user device with a second user device inaccordance with an embodiment of the present disclosure.

FIG. 12 illustrates an example method of creating a card via a sharingmodule in accordance with an embodiment of the present disclosure.

FIG. 13 illustrates a method of rendering a card at a second user devicebased on messages received from a first user device in accordance withan embodiment of the present disclosure.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

States of applications may be shared between user devices. For example,a recipe from a recipe application, a story from a news application, ora list of nearby restaurants from a restaurant application may beshared. Users can share web URLs with other users via messaging mediaassociated with the World Wide Web (WWW). Traditional mobileapplications are not configured to however allow for convenient sharingof application states. The examples disclosed herein provide systems andmethods for conveniently sharing application states, cards representinginformation about application states, application information, etc.between user devices.

A first user device may send a card to a second user device by creatinga data object including information related to a state of an application(referred to herein as an “application state” or “App state”) at thefirst user device. As used herein, a card may refer to a view of an appstate or of app state information, which is displayed in anotherapplication. The data object may include information from card recordsretrieved from a sharing server. The information from the card recordsis used at a second (or receiving) user device to display a cardincluding the information shared by the first user device. The carddisplayed at the second user device may be static or dynamic dependingon the type of information included in the corresponding app state. Someexamples of dynamic information, or information that varies by time orlocation, include local restaurants, taxis nearby, and/or airline flightprices. Some examples of static information are a restaurant's location,a restaurant name, a taxi current location, a movie name, an actor name,an airline flight time, and/or an airline flight departure location. Acard may represent a summary of the information included in theapplication state from which the data object was generated. The seconduser device may display the card including information corresponding tothe application state without opening the application associated withthe application state.

As another example, a first (or sending) device may share an app stateby generating and transmitting one or more messages includinginformation related to the app state to a second user device. Thesending device creates data objects including information about theshared app state and formats the data objects as one or more messages.In some embodiments, the sending user device may generate the dataobjects using an application that renders the shared application state.For example, a restaurant reviews application may share a state about aparticular restaurant from a first user device to a second user device.In other embodiments, the data objects may be generated by anotherapplication that displays information about the shared app state. Forexample, a search application may find search results about states of arestaurant reviews application and share the search results from a firstuser device to a second user device.

The receiving (or second) user device that receives the messages maydisplay, via a messaging application, the messages including informationfrom the data objects. The information may include a user selectablelink for accessing a card representing the shared application state. Acard may refer to a view of an app state that is rendered in a differentapplication (e.g., an application search result that is rendered in asearch application). A card can be rendered in a native applicationand/or a web browser application. Upon the user accessing a userselectable link, an application may render a card including a view ofthe app state. A sharing server may provide additional informationnecessary to render the card on the receiving user device. The sharingserver may include a resolver module that provides compatibility acrossmultiple user devices and platforms and/or serves as an intermediatenetwork device for allowing a first network device to share app stateswith other user devices. The sharing server stores card records,templates, user records, and configuration data to support rendering ofcards. Card records, templates, user records and configuration data arefurther defined below.

In some examples, a receiving user device displays an application stateas a card, which has a user selectable link. Upon the user selecting theuser selectable link, the receiving user device opens the same appimplemented on a sending user device. The receiving user device sets theapp on the receiving user device to the same state that the app is onthe sending user device. A data object generated at the sending userdevice may be formatted by a sharing module to be compatible with thereceiving user device. The sharing module may be included in the sendinguser device and/or a sharing server. The sharing module providescross-platform formatting and compatibility based on templates andconfiguration data.

In one example embodiment, a user of a first user device selects a sharelink associated with a displayed card. In response to selecting theshare link, the first user device displays menus respectively forselecting a sharing medium and a second user device. When the userselects a sharing medium that supports sharing of a data objectincluding information associated with the card, the sharing module ofthe first user device creates and shares the data object. The dataobject includes a set of data fields (e.g., in JavaScript® Object Notion(JSON) format, hypertext markup language (HTML) format, Javascript®format, etc.) that can be rendered as a card by a sharing module of thesecond user device. Messaging media supporting sharing of the dataobject may allow attachment of data object formats. The messaging mediamay be stored in and/or implemented as part of the sharing module. Inone embodiment, the messaging media may include a messaging formatimplemented by a launcher application for sharing cards displayed by thelauncher application.

A sharing module of a first user device may package informationassociated with a card into a data object and send the data object to asecond user device. The data object may include some or all of theinformation used to display the card at the first user device. In somecases, data tagged as static data may be sent in the data object, whiledata tagged as dynamic data may be omitted from the data object. Inother cases, data tagged as dynamic data may be sent in the data object.Options for packaging information into data objects may be selectedbased on custom rules, defaults for particular cards, and/or userselections.

Data for displaying a card includes data obtained from a card record,template data, and configuration data. Some or all of this data may beobtained from a sharing server at a remote server. Additionally oralternatively, some of the data may be cached at the first user device.For example, the first user device may maintain a cache of templates andconfiguration data. A transmitted data object may include some or all ofthe data obtained from a card record, template data, and/orconfiguration data. In some embodiments, the minimum data required toinclude in a data object is a unique identifier of a card record (e.g.,an application card identifier, access information, etc.). A sharingmodule at second user device may retrieve and obtain any other requiredinformation from the sharing server. The sharing server may find theother required information by identifying a card record using a uniquecard record identifier (e.g., application card ID, access information,etc.). The access information facilitates access to the correspondingapplication state. The access information may include native, web accessand/or download information.

The user device may launch (or execute) applications via a uniformresource locator (URL) and according to the access information. Theaccess information may include data that a user device uses to accessfunctionality provided by a corresponding native application.Accordingly, the process of launching the native application andperforming functions according to the access information may be referredto herein as launching the native application and setting the nativeapplication into a state that is specified by the access information.For example, access information for a restaurant reservation applicationcan include data that causes the user device 200 to launch therestaurant reservation application and assist in making a reservation ata restaurant.

The second user device renders a card associated with the data objectusing (i) data from the data object generated at the first user device,and (ii) any additional data obtained from the sharing server, a webserver, and/or an application programming interface (API). The seconduser device may use a template and configuration data as well asinformation from a card record. The card record may be obtained from thedata object or the sharing server for rendering the card. The sharingmodule at the first user device may be a part of a messaging applicationselected by the first user device or another application that receivesthe data object from the messaging application. In one example, thesharing module of the second user device is integrated with a launcherapplication installed at the second user device.

In some cases, the template used by the second user device to render thecard may be a different template than a template used by the first userdevice to render the card. Templates may specify how to render cardsusing native code of various platforms (e.g., ANDROID®, IOS®, etc.)and/or web formats (e.g., HTML and/or Javascript® formats). Accordingly,when sharing a card across the same or different platforms or betweenapps with different rendering methods (e.g., web versus native renderingmethods), different templates may be used at the first and second userdevices.

The different templates may match a same template identifier (ID). Theuser devices may cache compatible templates locally on each of the userdevices and/or additional required templates may be obtained from thesharing server upon request for templates. The request for templates mayidentify the platform and/or rendering method of the requested template,such that the sharing server may identify and obtain the correcttemplate to return to the requesting user device.

Multiple templates are provided for each platform and rendering methodbased on card types. For example, templates may include restauranttemplates, local business templates, event templates, and generictemplates for displaying different types of cards. These differenttemplates are selected to render a card by a template identifier storedin the corresponding card record. In some cases, a particular templatemay not be available for a chosen platform and/or rendering method. Ageneric template may be selected by the sharing module or sharingserver, such that the card can be displayed by the sharing module. Inother examples, the sharing module may obtain and use a best matchtemplate instead.

Configuration data maps data from a card record to particular fields ofa template. A template populated with data from a card record may bedisplayed as a card. The template may include instructions for obtaininginformation to populate fields of the template when the information ismissing. Instructions may be in the form of URLs and/or instructions foraccessing an API. In some examples, the instructions may includeinstructions to retrieve the data from a sharing server.

In another example embodiment, the first user device displays an appstate that a user is to share with a second user of a second userdevice. In this embodiment, a sharing module integrated with theapplication displaying the app state obtains from the sharing serverinformation for creating a data object to send to the second userdevice. The sharing module may obtain, from the application displayingthe app state, information for identifying the card record correspondingto the app state. In some embodiments, the information may be accessinformation associated with the app state, which the sharing server mayuse to find a card record including the access information. In otherembodiments, the information may be keywords and/or text extracted fromthe app state, along with the name of the application, which may be usedto find a matching card record. After retrieving the information forcreating the data object, the sharing module creates and sends the dataobject to the second user device for display on the second user device.

In another example embodiment, the sharing module of the first userdevice sends the data object to a sharing server along with instructionsto share the data object with the second user device. Based on userprofiles stored at the sharing module, the sharing server formats a cardfor display at the second user device and sends the card to the seconduser device. The sharing server may format the card for display basedon: an identified card record; a template matching a card renderingmethod and/or an operating system of the second user device; and/orconfiguration data matching the template.

In embodiments where the second user device displays the shared card viaa launcher application, the launcher application may dedicate a specialscreen for displaying cards. The launcher application may store cachedtemplates and configuration data, communicate with the sharing server,and/or share the cards with other user devices. FIGS. 1-2 show a sharingsystem 100 that includes a user device 200 associated with a user 10 andin communication with a service provider network 110 via a distributednetwork 120. The service provider network 110 may be a distributedsystem (e.g., cloud environment) having scalable/elastic computersand/or other remote computing devices 112 and/or storage devices 114.The user device 200, the service provider network 110, and a sharingserver 400. The sharing server 400 and/or the user device 200 mayimplement a sharing module (shown as sharing module 410 in the sharingserver 400 and additionally or alternatively as sharing module 412 inuser device 200). The sharing module optionally receives data from oneor more data storage devices 130 or one or more other user devices 200.In some implementations, the sharing server 400 communicates with theone or more user devices 200 and the data storage devices 130 via thedistributed network 120. The distributed network 120 may include varioustypes of networks, such as a local area network (LAN), a wide areanetwork (WAN), and/or the Internet.

The data storage devices 130 may correspond to a variety of differentdata providers. The data storage devices 130 may include applicationdeveloper data 130 a corresponding to application developers' websitesand data feeds provided by developers. The data storage devices 130 mayinclude operator data and digital distribution platform data 130 bconfigured to distribute native applications 210 to user devices 200. Asan example this may include digital distribution platform datacorresponding to the GOOGLE PLAY® digital distribution platform byGoogle®, Inc.

The data storage devices 130 may also include other website dataassociated with websites and web log data 130 c (i.e., blog data),application review data 130 d, and/or other website data including datarelated to native applications 210. Additionally, the data storagedevices 130 may include social networking data 130 e corresponding tosocial network sites, such as FACEBOOK® by Facebook®, Inc. (e.g.,Facebook posts) and TWITTER® by Twitter® Inc. (e.g., text from tweets).Data storage devices 130 may also include online databases 130 f thatinclude, but are not limited to, data related to movies, televisionprograms, music, and restaurants. Data storage devices 130 may alsoinclude additional types of data sources in addition to the data sourcesdescribed above. Different data storage devices 130 have correspondingcontent and data update rates.

A native (or software) application refers to computer software that,when executed by a computing device, causes the computing device toperform a task. In some examples, a native application is referred to asan “application,” an “app,” or a “program.” Example softwareapplications include word processing applications, spreadsheetapplications, messaging applications, media streaming applications,social networking applications, and games.

Referring now also to FIG. 3A, the user device 200 may be any computingdevice capable of displaying an application state 302 or card 220 on adisplay 206 by way of the GUI 204. An application state 302 is adisplayed state of an executed application. As an application isexecuted and a user 10 interacts with the application, each additionalinteraction places the application in a new resulting application state.Generally, an opening splash screen may not be considered an applicationstate 302, but any state or screen after the splash screen is consideredan application state 302. An application state allows for theinformation included within an application to be used outside theapplication that created that application state. In addition, a userdevice processor 270 is capable of executing the one or more installedapplications. The user device 200 may be a mobile computing device, suchas a laptop, a tablet, a smart phone, and a wearable computing device(e.g., headsets and/or watches). A user device may have other formfactors, such as a computing device included in a desktop computer, avehicle, a gaming device, a television, or other appliance (e.g., anetworked home automation device or a home appliance).

The user device 200 includes an operating system 216. In examples wherethe user device 200 is a mobile device, the user device 200 may run anoperating system, such as ANDROID® developed by Google® Inc., IOS®developed by Apple® Inc., or WINDOWS PHONE® developed by MicrosoftCorporation. Accordingly, the operating system 216 running on the userdevice 200 may include, but is not limited to, one of ANDROID®, IOS®, orWINDOWS PHONE®. In an example where a user device 200 is a laptop ordesktop computing device, the user device 200 may run an operatingsystem, such as MICROSOFT WINDOWS® by Microsoft Corporation®, MAC OS® byApple®, Inc., or Linux®. The user device may also access the sharingserver 400 while running the operating system 216.

Applications may be executed on a variety of different user devices. Insome examples, a native application 210 is installed on a user deviceprior to a user 10 purchasing the user device. In other examples, theuser 10 downloads and installs the native applications 210 on the userdevice 200.

The functionality of an application may be accessed on the user deviceon which the application is installed. Additionally or alternatively,the functionality of an application may be accessed via the remotecomputing devices 112. In some examples, all of an application'sfunctionality is included on the devices 112, 200 on which theapplication is installed. In other examples, an application installed ona user device 200 accesses information from other remote computingdevices 112 during operation. For example, a weather applicationinstalled on a user device 200 accesses the latest weather informationvia the Internet and displays the accessed weather information to theuser 10 via the installed weather application. In still other examples,a web-based application 212 (also referred to herein as a webapplication) is partially executed by the user's computing device andpartially executed by one of the remote computing devices 112. Forexample, a web application may be executed, at least in part, by a webserver 332 (shown in FIG. 3C) and accessed by a web browser of theuser's computing device. Example web applications may include aweb-based email, online auctions, and online retail sites.

The user device 200 may have limited display area on the display 206 todisplay icons, application states 302 and/or information from otherapplications. It is desirable to organize application state informationinto a card 220 presenting the same or similar information. Therefore,when sharing information between applications and users, the sharingserver 400 formats the information included in the application state 302into a card 220 by transmitting the relevant information displayed inthe application state 302 using data stored in memory 420 (or sharingdata store) of the sharing server 400.

In general, the sharing modules 410, 412 display and/or shareapplication states and cards 220. The user device 200 executesapplications that may interface with the sharing module 410. Moreover,the user device 200 may communicate with the sharing server 400 usingapplications including native applications and browser applications.Although the user device 200 may communicate with the sharing server 400using a native application and/or a web-browser application, the userdevice 200 may be described hereinafter as using an application tocommunicate with the sharing server 400. In some implementations, thefunctionality attributed to the sharing server 400 or sharing module 410is included as a display or sharing component of a larger applicationthat has additional functionality. For example, the functionalityattributed to the sharing module 410 may be included as part of a nativeapplication or a web application as a feature that provides sharing ofapplication states 302 by way of the GUI 204 on the display 206.

As shown in FIG. 2, the sharing server 400 includes the sharing module410 and a resolver module 440. The resolver module 440 is incommunication with the memory 420. The user device 200, sharing server400, and data storage devices 130 are in communication with each other.

The memory 420 stores information, such as templates 422, user records424, operating systems of user devices 200, configuration data 426, cardrecords 430 (representing application states), and/or other additionalinformation. The templates 422 include information on how to format adata object 320 into a presentable format across multiple user devices.In some examples, a template 422 is not available for the applicationstate 302 and/or data object 320. In these cases, the sharing module 410may create a new template based on a similar template 422 and/or accessthe service provider network 110 and download appropriate template(s).For example, the template 422 may be selected based on a threshold fitof the data object 320 to the template 422. If the data object 320 doesmatch with the template 422 or have a threshold fit, a default templatemay be selected from a collection of default templates. A template 422may be selected as the closest approximation of the data object 320 orbased on a matching field.

Referring now also to FIG. 4, the matching field may be a title 435 a, adescription 435 b, an image 435 c, and/or additional data fields 435 dincluded in the card object 430. In some examples, a data object 320including an application state 302 from a restaurant is placed in ageneric template for a business if a specific restaurant template is notavailable. A simple template may specify image, title and description,whereas a more complex template may include more specific informationand how the information is to be displayed.

The templates 422 include information from card records 430 as apresentable card across multiple user devices. The memory 420 may storetemplates for different rendering methods. A web template may specify acard in a web format (e.g. HTML and/or Javascript®). Similarly, anANDROID® template may specify how to render a card on an ANDROID®operating system (e.g., using native ANDROID® code, native ANDROID®widgets, etc.). Moreover, for each rendering method, the memory 420 maystore different types of templates for displaying different types ofinformation. For example, memory 420 may store templates for a carddisplaying information about a restaurant, templates for a carddisplaying information about an event, templates for a card displayinginformation about a product, and the like. The card records 430 specifythe correct type of template using a template identifier 436. Moreover,a particular template may be selected by the sharing module 410 orresolver module 440 in accordance with a selected rendering method(e.g., web, native, etc.).

The user records 424 may include information regarding the user device200 that is sharing or receiving the data object 320, such as a username, a device type, a device operating system, a display size, adisplay type, installed applications, allowed users, blocked users,preferences, and or other information. The configuration data 426 mayinclude information on how to map the cards 220 or application states302 into a data object 310 or how to display the data object 310 intocards 220 or application states 302. The configuration data 426 mayinclude information on how to map information from card records 430 intothe templates 422 in order to render cards 220. The configuration data426 may be a binding file that maps fields in the application stateinformation 434 to fields in the template 422. This allows the template422 to be populated by the proper fields, such as title 435 a,description 435 b, image 435 c, and additional data fields 435. Theconfiguration data 426 may also include formatting data, such as fontsize/color. In some embodiments, the configuration data 426 isplatform-specific, but may be platform-agnostic if a given template 422uses the same naming conventions across various platforms. Theconfiguration data 426 can be transmitted as part of the data object 320or downloaded from the memory 420. The combination of informationincluded in the memory 420 allows the sharing module 410 and sharingserver 400 to convert and display the relevant information included in acard 220 or application state 302 across multiple user devices 200 andoperating systems 216. The sharing server 400 may also provide aconnection distributing the shared data object 310 between multipleusers 10 in the correct format.

In some implementations, as shown in FIG. 2B, the sharing module 410 isincluded on the user device 200. The user device 200 may have aparticular application state 302 displayed. The user device 200 mayrequest the application card ID 432 or card record 430 from the memory420 via the sharing module 410 or 412. In some examples, if the userdevice 200 is sharing the application state 302, the sharing module 410creates a data object 320 containing the card record 430 or applicationcard ID 432. In at least one embodiment, the user device 200, via thesharing module 410, sends to the memory 420 the current applicationstate 302 and access information 202 and receives the matching cardrecord 430 corresponding to the access information 202. After receivingthe application card ID 432, the user device 200 may send the staticinformation to a second user device omitting dynamic information. If theuser device 200 is receiving the data object 320, the sharing module 410may render and display the data object 320 as a card 220. Additionalinformation such as static information or dynamic information may beretrieved using an application program interface (API) to complete thecard 220.

In some embodiments, the sharing module 410 may be integrated with anative application of a sending user device. For example, a nativeapplication may include the sharing module 410 and a library (e.g., adynamic library). As part of a native application, the sharing module410 creates the data object(s) 320 that are sent to a receiving userdevice as message(s) 224, which is shown in FIGS. 3E, 3F. In someexamples, the sharing module 410 may generate data objects 320 forsharing an application state of the native application. In otherexamples, the sharing module 410 may generate data objects 320 forsharing a card 220 representing a state of a separate application. Auser may select a share button 222 for sharing an application state 302or card 220 in a native application that integrates the sharing module410. When a user shares a state or card, the sharing module 410 maygenerate the data objects 320 from information corresponding to thestate or card. In some embodiments, the sharing module 410 accessessharing server 410 to obtain additional information for the data objects320.

The sharing module 410 formats one or more data objects 320 fortransmission to a receiving user device 200 b via a messaging medium,for example, via text messages, chat messages, e-mails, and/or the like.The specific format may be selected based on the sharing medium selectedby a user. For example, if a user selects share option 222A in order toshare via a short messaging service (SMS) message, the messages may beformatted in a SMS format (e.g., plain text, separated into segments of140 characters or less, etc.). In another example, if a user selectsshare option 222C in order to share via email, the messages may beformatted in a format that can be rendered via an email application(e.g., using HTML or some other supported markup language). Sharingmodule 410 may use information selection rules for each sharing mediumin order to format the data objects accordingly. Formatting the dataobjects as messages may involve processing data object information, forexample, truncation or concatenation of text fields, formatting URLs aslinks, resizing images, etc.

FIG. 3A shows the user device 200 and user selectable buttons 222 a-ihaving corresponding links (referred to as user selectable links 222a-i), where i is an integer greater than or equal to 1. In this example,the user device 200 displays an app in a given state referred to as anapp state 302. The app state 302 is representative of informationdisplayed to a user and may interact with the user. The links 222 a-imay be displayed together with a card 220. Each state of the app may becategorized and/or stored as a card record 430.

As an example, the user selects a user selectable link on the userdevice 200 by interacting with the link (e.g., touching or clicking thecorresponding button). In response to selection of a link 222 (e.g.,link corresponding to the “Share” button displayed in the exampleshown), the user device 200 may launch a corresponding softwareapplication (e.g., a native application or a web-browser application).The user may be prompted to provide additional information on how or towhom the app state may be shared. In some examples, the first set ofrequests to the user includes selecting a messaging medium for how theuser wants to share the information. Examples include sharing via sharelink 222, SMS link 222 a, hangout application link 222 b, email link 222c, Bluetooth® link 222 d, or launcher application link 222 e. In thisexample, the user selects the SMS application link 222 a or the launchlink 222 e. The SMS application link 222 a corresponds to an applicationspecifically tailored to share application states for sending SMSmessages between multiple user devices 200. The launch app associatedwith the launch application link 222 e may accept a shared app state, adata object, and/or a card record and display a card representative ofthe information included in the app state, the data object, and/or thecard record. The SMS application may accept data from the data objectand create messages 224 shown in FIGS. 3E, 3F.

The launch app may also allow a receiving user to select the card (e.g.,card 220) and open an application from which the application state 302,data object 320, or card record 430 was generated and shared. Thereceiving user device of the receiving user may set the application tothe same state as the application state 302.

An SMS application may accept data from the data object 320 and createmessages 224 therefrom. After selection of a messaging medium forsharing an app state, a user may be prompted by user selectable links222 to whom the application state 302 is to be shared. Examples includeand are shown as Abhay 222 f, Xiao 222 g, Bennett 222 h, and/or Tom 222i. In the example shown, Abhay 222 f is selected. The sharing modulepackages the application state information into a data object 320including information to recreate the app state 302 on another userdevice 200. In some examples, information packaged in the data object320 is based on a tag of the data. Examples of the tag include location,sharable, static, dynamic, and/or other retrievable data via API 330.Given tags may be selected to be included in the data object 320 basedon factors, such as server usage, bandwidth, server load, availablebandwidth, and/or a number of server requests, etc. The sharing modulepackages information into data object(s) 320 for formatting as messages224 to send to receiving user device 200 b.

In some examples, the data object 320 is a JSON block of data. The JSONblock is a light-weight data interchange format that is suitable formoving data and information between multiple user devices 200. The dataobject 320 may include the card record 430. The card record 430 isdiscussed in detail with reference to FIG. 4 below. The app state 302transmitted using the data object 320 may be either static or dynamic. Astatic application state displays the same information as the sharinguser device 200 on the receiving user device 200.

A dynamic app state may display the same (or similar) state of theapplication displayed on the sending user device, but the correspondinginformation displayed is different based on settings in the receivinguser device. When the application state is a dynamic application state,the receiving user device may alter the application state based oninformation from the sending user device. The information may include alocation of the receiving user device, an IP address of the receivinguser device, a setting of the receiving user device, user inputs, and/oruser data. For example, if an application state for restaurants near alocation of a user is to be shared, the application state may be sharedusing different techniques. If the application state is shared as astatic application state, then the receiving user device is providedwith restaurants near the sending user device. If the application stateis shared as a dynamic application state, then the receiving user deviceis provided with restaurants near the receiving user device and not thesending (or sharing) user device.

As an additional example, if an application state for taxis near thesending user device is to be shared statically, the application state onthe receiving user device shows taxis near the sending user device. Ifthe application state is shared dynamically, the receiving user devicemay see taxis near the receiving user device and not near the sharinguser device. In some examples, only parts of an application state areshared statically and other parts are shared dynamically. Using theexample of a sharing user device sharing the application state of a listof restaurants near the sharing user device, the application state mayinclude a list of restaurants within a given distance of the sharinguser device and a distance from the sharing user device to each of therestaurants. The receiving user device may receive an application statedisplaying the list of restaurants statically and the distances to therestaurants dynamically. As a result, the receiving user device displays(i) a list of restaurants near the sharing user device that was sharedstatically, and (ii) the distances from the receiving user device toeach of the restaurants.

FIG. 3B shows a user device 200 a sharing an application state 302,which is displayed as a card 220 on a receiving user device 200 b. Thesharing user device 200 a has initiated a user selectable link 222requesting to share the contents of the application state 302 to thereceiving user device 200 b. The sharing user device 200 a may send adata object 320 related to the application state 302 via the distributednetwork 120 to access the sharing server 400 and retrieve a card record430 from the sharing server 400. The data object 320 may include theinformation related to the application state 302. The receiving userdevice 200 b receives the data object 320 through the distributednetwork 120 and displays the information included in the data object 320in the card 220. In at least one example, the data object 320 includesapplication card ID 432. Using the application card ID 432 in the dataobject 320, the sharing server 400 may populate the remainder ofinformation used to display the card 220 on the receiving user device200 b. In some examples, the receiving user device 200 b receives thedata object 320 including the application card ID 432 and requests anyadditional information from the sharing server 400 using the distributednetwork 120 to populate the card 220.

The card 220 may be a graphical representation of the actual data in theapplication state 302 or a text format presenting similar or reducedinformation shown in the application state 302. The card 220 may includea user selectable link that when selected causes the same app to beopened as the app corresponding to the application state 302. The appexecuted on the receiving user device 200 b is set to the same state asthe app state 302. In some examples, the user selectable link of thecard 220 when selected causes a display app to open that displays a fullscreen version of the application state 302 without requiring the userto have the same app installed that generated the application state 302and resulting data object 320. In some examples, the user selectablelink of the card 220 prompts the user to agree to having the app thatgenerated the application state 302 installed. Upon installation of theapp, the app is opened to the same state as the application state 302.

The data object 320 generated by the sharing user device 200 a may besent via the distributed network 120 to a sharing server 400. Thesharing server 400 may reformat the data object 320 into a suitableformat depending on the receiving user device 200 b, such as when thereceiving user device 200 b is unable to interpret or display theinformation included in the data object 320 from the card 220. Thereceiving user device 200 b may also (i) send the received data object320 back to the sharing server 400 for reformatting to be appropriatefor the operating system of the receiving user device 200 b, and/or (ii)request a template 422 that is appropriate to display the data object320.

FIG. 3C shows the user device 200 a sharing an application state 302 anddisplaying the app state as a card 220 on the user device 200 b. Thesharing user device 200 a may send a data object 320 including theinformation from the application state 302 to the receiving user device200 b via the distributed network 120. The receiving user device 200 breceives the data object 320 and converts the data object 320 into acard 220, which includes at least one of the same information presentedin the application state 302. In some examples, the card 220 ispresented inside of a messaging application. An application on thesecond user device 200 b may display additional messages or userselectable links 222, 222 a,b in addition to the card 220. The firstmessage or user selectable link 222 a may be from the first user device200 a. The second message or user selectable link 222 b may be generatedby the second user device 200 b and sent to the first user device 200 a.The card 220, messages and/or user selectable links 222, 222 a,b may befrom different and or multiple user devices. The sending user device 200a and/or the receiving user device 200 b may be integrated with asoftware development kit (SDK) 444 including API 446, which are shown asbeing stored in the memory 280 in FIG. 5. The API 446 expresses asoftware component in terms of its functionality, operations, data type,various inputs and outputs. The API 446 may communicate with and/orobtain software, information and/or data from the API server 330. If thereceiving user device 200 b is operating an application integrated withthe SDK 444 and a correct API, the application may display the card 220related to the application state 302 of the sharing user device 200 aincluded in the data object 320. The application may choose to integratethe card 220 as a user selectable link 222 and integrate with additionalsoftware included in the application, such as search and/or messagingsoftware.

In one example, the user selectable links 222 a-d are messages sharedfrom the sharing user device 200 a or an additional third user device200. The cards 220 are displayed in a similar format as the userselectable link messages and allow the user to select the card 220. Uponthe user selecting the card 220, the application may open a similarapplication as the one sent in the data object 320 and set theapplication to the same state as specified in the data object 320.Additionally, the SDK 444 and API 446 may include the necessaryinformation to display, render or interpret the data object 320 on theGUI 204 of the application into a card 220 with a user selectable link222.

In some implementations, the data object 320 includes the applicationcard ID 432. The data object 320 is sent to the receiving user device200 b. The receiving user device 200 b requests additional informationfrom the sharing server 400 related to the application card ID 432, suchas configuration data 426, template data 422, other information includedwithin the card record 430, etc. The receiving user device 200 b mayrequest additional information from the API 446 and/or the API server330. The API 446 may access web server 332. The web server 332 mayprovide additional information to the receiving user device 200 b inorder to populate the card 220. In some examples, the data object 320includes the application card ID 432 and/or other information that issent to the sharing server 400. The sharing server 400 returns a partialor complete card record 430 and optionally includes the template(s) 422,user records 424, and/or configuration data 426.

FIG. 3D illustrates an example first user device 200 a sharing a firstapplication state 302 a to a second user device 200 b displayed as asecond application state 302 b. Upon the user 10 selecting the userselectable link 222 “share”, the first user device 200 a packagesinformation regarding the application state 302 into the data object320. The data object 320 is transmitted via the distributed network 120to the sharing server 400. The sharing server 400 processes the dataobject 320 to determine the desired second user device 200 b. Thesharing server 400 compares the information in the data object 320 tothe operating system or type of device of the second user device 200 b.This information may be stored in the memory 420 or requested from thesecond user device 200 b via the distributed network 120.

The sharing server 400 may then convert the data object 320 into theproper format or template 422 that is readable by the second user device200 b. The second user device 200 b may display the first applicationstate 302 a as a second application state 302 b or as a card 220including the same information as the first application state 302 a. Thesecond user device 200 b may also display the second application state302 b if the second user device 200 b does not have the application thatcreated the first application state 302 a installed on the second userdevice 200 b. If the second user device 200 b does not have theapplication that created the first application state 302 a, the user ofthe second user device 200 b may be prompted to install the application.In some examples, the data object 320 includes some of the data topopulate the template(s) 422. The remainder of the template(s) 422 ispopulated from template data. The template data may be retrieved fromthe distributed network 120 or from the sharing server 400. The templatedata may include static or dynamic object data or other object data,such as image data, description data, format data, graphic data, mediadata, and/or audio data, etc.

When receiving a data object 320, the second user device 200 b maycompare the included data in the data object 320 to a template 422 andrequest any additional data to complete the template 422 from thesharing server 400, a third party server, or from internal memory. Theadditional data may be referred to as template data. In some examples,template data is received from multiple sources by the second userdevice 200 b. The template data may be used to populate or complete acard 220. In some examples, the template data 220 is sent from thesharing device 200 a and stored on a server and/or the sharing server400 until the template data 220 is requested to populate a template. Thetemplate data may be kept on the server and/or sharing server 400 and beused repeatedly without additional uploads.

In some implementations, a memory of the sharing user device 200 astores the card record 430, configuration data 426, and/or template data422. The sharing user device 200 a may include the data to render thecard 220 and/or the application state 302. The card record 430 mayinclude the application card ID 432, the application state information434, access information 202, and the template ID 436. The sharing userdevice 200 a may select the data to populate the card record 430 basedon information that may be obtained from the API server 330 or webserver 332. In some implementations, the data provided by the sharinguser device 200 a is adequate to render the card 220 and prevents thereceiving user device 200 b from having to access the sharing server 400to display the card 220. The sharing user device 200 b may optionallycontact the sharing server 400 or API server 330 to verify and/orcollect additional information required to render the card 220. In someembodiments, as shown at FIG. 3B, users may select a share link 222associated with a card 220. In these embodiments, the sharing module 410may embed application state information 434 associated with the card 220into one or more data objects 320. The sharing module 410 may formatdata objects 320 for sending in one or more messages 224 based on theselected messaging medium.

For example, the sharing module 410 may send description data 435 b toanother user as a text message. Additionally or alternatively, thesharing module may embed image data 435 c in another message, such as animage message. The sharing module 410 may also embed a resolver URL 438in a text message. The resolver URL 438 can be included within themessage including description data 435, in a separate message, or in amessage together with some other information. The sharing module 410 mayuse tags associated with application state information 434 in order toselect information for a particular data object. For example, the card220 may include image data 435 c tagged as an “image,” description data435 b tagged as a “description,” a resolver URL 438 tagged as a“resolver URL,” etc. The sharing module 410 may select informationassociated with particular tags for packaging as data object(s) andshare the information according to information selection rules. If thesharing module 410 needs additional information beyond the dataassociated with the card 220, the sharing module 410 may send a requestto the resolver module 440 identifying the card record 430 (e.g., usingthe application card ID 432 and/or resolver URL 438) and thecorresponding data fields. The resolver module 440 finds the matchingcard record 430, extracts the requested data, and returns the matchingcard record 430 to the sharing module 410.

When the data objects 320 are sent as messages 224, the data objects 320may be arranged in one or more messages. In one example, as illustratedby FIG. 3E, the sharing module 410 may cause the sending user device 200a to transmit an image message first, followed by a description message,and concluding with a message including the resolver URL 438 formattedas a link. In another example, a first message may include an image anda second message may include a description concatenated with a resolverURL 438 formatted as a link.

In other embodiments, as shown at FIG. 3C, users may select a share link222 associated with an application state 302. The integrated sharingmodule 410 may display a share link 222 in order to share a state of theapplication. In some examples, the sharing module 410 causes the sharelink 222 to be displayed separate from the rest of the application state(e.g., adjacent to the application state 302, hovering over theapplication state 302, etc.). In other examples, the sharing module 410causes the share link 222 to be displayed within the application state302, for example, by injecting code for rendering the share link 22 intothe rendering code for the application state.

In these embodiments, the sharing module 410 may generate data objects320 from information obtained from the rendered application state 302.For example, the sharing module 410 may capture a screenshot of all or aportion of the application state 302 in order to send the capturedscreenshot as an image message. The sharing module 410 may requestadditional information from the sharing server 400. The sharing server400 (in particular resolver module 440) may receive the request and finda card record 430 that matches the application state 302 from the memory420 based on a query provided by the sharing module 410.

When accessing additional information about a state from the sharingserver 400, the sharing module 410 creates a query comprisinginformation associated with the rendered application state. For example,the sharing module 410 may embed a name of the application in the query.Furthermore, the sharing module 410 may extract keywords and/or textfrom particular fields of the rendered application state to embed in thequery. The resolver module 440 may then find the matching card record430. The sharing server 400 responds with information from a matchingcard record 430 in response to the query (e.g., a resolver URL 438, adescription 435 b, and/or an image 435 c).

The resolver module 440 may provide application state information 434from a card record 430 to the sharing module 410. In some embodiments,the resolver module 440 may provide the whole card record 430. In otherembodiments, the sharing module 410 may specify which informationresolver module 440 should extract and return. Additionally, theresolver module 440 may provide the resolver URL 438 that directs backto the resolver module 440. The resolver module 440 may run a webserver, such that user devices may access the resolver module 440 via aweb browser application using the resolver URL 438.

FIG. 3G shows selection of a link including the resolver URL 438 at thereceiving device 200 b. A user of the receiving 200 b may select thelink including resolver URL 438 embedded in the received message 224 byselecting or clicking a card or button (e.g., card 224 a, buttons 224 b,224 c) corresponding to the message 224 including the resolver URL 438.Selecting the resolver URL 438 may cause the receiving device 200 b tocheck a URL handler module 448 to select which application shouldreceive the resolver URL 438.

The URL handler module 448 (e.g., a custom URL handler module on IOS® oran intent filter on ANDROID® operating systems) specifies whichapplication should intercept and handle a URL that meets a predefinedpattern. By default, URLs that start with the string “http://www” may behandled by a web browser. In one embodiment, other URL handler modulesmay override a default handler module (e.g., the URL handler module 448)if a URL matches a more specific pattern (e.g., the URL includes aspecified domain name such as “quixey.io”).

When the sharing module 410 is not installed at a user device, theresolver URL 438 may be handled by the web browser application 211.Accordingly, when a user selects a message or link including thereceived resolver URL 438, the web browser application 211 interceptsand handles the resolver URL 438. In particular, the web browserapplication 211 of the receiving user device 200 b may access the webserver 332 specified by resolver URL 438, which is running on sharingserver 400.

The resolver module 440 detects that the web browser application 211 hasrequested a webpage corresponding to the resolver URL 438. Accordingly,resolver module 440 may generate a web page including the card 220 andtransmit the card 220 to the receiving user device 200 b. The resolvermodule 440 generates the web page by: finding the card record 430matching the resolver URL 438; selecting a template 422 matching thetemplate identifier 436 of the card record 430 and selected renderingmethod; and retrieving configuration data 426 for the selected template422. In this example, the template 422 is a web card template. Inparticular, the resolver module 440 populates the matching web cardtemplate 422 with application state information 434 as specified by theconfiguration data 426. For example, the configuration data 426 mayindicate that a data field of the template tagged as an “image” shouldbe populated with image data 435 c.

In some cases, if the card record 430 includes web access information202, the resolver module 440 may associate the web access information202 with a link field of the template 422; such that a user clicking ona link embedded within the card 220 can access a web page correspondingto the shared application state 302. In other cases, the resolver module440 may select application access information that works with theoperating system of the receiving user device 200 b based on the useragent string received from the web browser application 211. A user agentstring is a string provided with a hypertext transfer protocol (HTTP)request by the web browser applications 211 for identifying therequesting user device. For example, a user agent string of “Mozilla/5.0(iPad; CPU OS 7_0 like Mac OS X) AppleWebKit/537.51.1 (KHTML, likeGecko) CriOS/30.0.1599.12 Mobile/11A465 Safari/8536.25(3B92C18B-D9DE-4CB7-A02A-22FD2AF17C8F)” may indicate that the receivinguser device 200 b is an IOS® device. Accordingly, in some embodiments,the resolver module 440 may populate the template 422 with applicationaccess information specific to the operating system of the receivinguser device 200 b.

The resolver module 440 embeds the populated template 422 as a card 220in a webpage. The webpage may be returned to the browser and rendered atthe receiving user device 200 b. A user of the receiving user device 200b may select a link associated with the card 220 to access the embedded(web or application) access information 202.

When the sharing module 410 is installed at the receiving user device200 b, additional software may be activated. If a user selects a linkincluding the resolver URL 438 (e.g., clicks on the button correspondingto the message 224 and including the resolver URL 438 formatted as alink), the sharing module 410 may cause the card 220 to be rendered byan integrated native application. For example, the sharing module 410installed as part of a launcher application may cause the card 220 to berendered in a special window of the launcher application. In otherexamples, the sharing module 410 installed in an application forsearching and finding other applications may render the card 220.

The sharing module 410 may register a handler module that designates thedomain name of the resolver URL 438. Accordingly, in one example, thenative application integrated with the sharing module 410 may interceptthe selected resolver URL 438 when a user of the receiving user device200 b selects the resolver URL 438 from the messaging application. Forexample, a launcher application may intercept the resolver URL 438 andprovide the resolver URL 438 to the embedded sharing module 410.

The sharing module 410 at the receiving user device 200 b communicateswith the sharing server 400 in order to render the card 220. The sharingmodule 410 sends a query including the resolver URL 438 to the sharingserver 400. Moreover, the sharing module 410, in an example, may embedin the query information: the operating system of the received userdevice 200 b; whether an application pertaining to the application state302 is installed; and a selected rendering method. The selectedrendering method may also indicate whether the application is to renderthe card 220 using a native operating system code or a web code.

In some embodiments, the sharing module 410 may detect whether anapplication is installed by matching a parameter of the resolver URL 438to a list of installed applications. For example, a resolver URLindicating an example restaurant state may behttp://quixey.io/RestaurantApp/ViewRestaurantById/12345. In thisexample, “RestaurantApp” is the name of the restaurant. The sharingmodule 410 may detect whether the RestaurantApp is installed byextracting the application name parameter from the resolver URL 438 andcomparing the application name parameter to a list of installedapplications provided by the operating system of the receiving userdevice 200 b.

The resolver module 440 may: locate the card record that matches theresolver URL 438; locate a template 422 matching the template identifier436 of card record 430; determine the selected rendering method; andlocate configuration data matching the template 422. The resolver module440 generates the card 220 by populating the template 422 withapplication state information 434 according to configuration data 426.The resolver module 440 may select particular access information 202based on the indication from the sharing module 410 of whether acorresponding application is installed. For example, if the applicationspecified by the card record 430 is not installed, the resolver module440 may select access information 202. If the application specified bythe card record 430 is installed, the resolver module 440 may selectaccess information for the specified operating system. The resolvermodule 440 returns the populated template 422 as the card 220 forrendering at the received user device 200 b.

In some implementations, the receiving user device 200 b may requestadditional information from an API server 330 in order to finishpopulating the card 220. The template 422 may include instructions forthe sharing module 410 to access the API 446 and finish populating thecard 220. The instructions may access an API server 330 or local files.The API server 330 may provide additional information to the receivinguser device 200 b in order to populate the card 220.

FIG. 4 shows the card record 430 that is based on an app state. The cardrecord 430 includes data related to a state of the app. The card record430 may include an application card identifier (ID) 432, applicationstate information 434, a template identifier 436, and access information202 used to provide features provided by an application.

The application card ID 432 may be used to identify the card record 430and may be a string of alphabetic, numeric, and/or symbolic characters(e.g., punctuation marks) that provides a unique ID that distinguishesthe card record 430 from other card records stored in the memory 420(shown in FIG. 6). In some examples, the application card ID 432describes a function and/or an application state in human readable form.For example, the application card ID 432 includes the name of theapplication referenced in the access information 202. In a specificexample, an application card ID 432 includes the name of an Internetmusic player application and a song name. The song associated with thesong name is played when the Internet music player application is setinto the state defined by the application access information included inthe application state.

In some examples, the application card ID 432 includes a string in theformat of a URL, which may uniquely identify the card record 430. Insome examples, the string includes multiple parameters used to retrievethe corresponding card record 430. In addition, some parameters may beuser-generated, which results in creation of a new card record thatincludes the parameters and has a corresponding application that has notbeen previously executed. Thus, the user-selectable link 222 may notexplicitly correspond to a known end result inside the application, butsimply fits a known link expression that the application accepts. Forexample, the UBER® application may display a user selectable link 222that uses a latitude and a longitude as parameters to determine alocation. In some examples, the application card ID 432 is included inthe resolver URL 438, such that resolver module 440 is able to find thecard record 430.

In another example, if the card record 430 describes a function of theYELP® native application, the application card ID 432 may include thename “Yelp” along with a description of the application state describedin the application state information 434. For example, the applicationcard ID 432 for the card record 430 that describes the restaurant named“The French Laundry” may be “Yelp—The French Laundry.” In an examplewhere the application card ID 432 includes a string in the format of aURL, the application card ID 432 may include the following string“http://www.yelp.com/biz/the-french-laundry-yountville-2?ob=1” touniquely identify the card record 430. In additional examples, theapplication card ID 432 may include a URL using a namespace other than“http://,” such as “func://”, which may indicate that the URL is beingused as an application state ID in an application state. For example,the application card ID 432 may include the following string“func://www.yelp.com/biz/the-french-laundry-yountville-2?ob=1”.

The application state information 434 includes data that describes anapplication state into which an application is set according to theaccess information 202 in the card record 430. Additionally oralternatively, the application state information 434 includes data thatdescribes the function performed according to the access information 202included in the card record 430. The application state information 434may include text, numbers, and symbols that describe the applicationstate. The types of data included in the application state information434 may depend on the type of information associated with theapplication state and the functionality specified by the accessinformation 202. The application state information 434 may include avariety of different types of data, such as structured, semi-structured,and/or unstructured data.

In some examples, the application state information 434 includes datathat is presented to the user 10 by an application when the applicationis set in the application state specified by the access information 202.For example, if the access information 202 includes application accessinformation, the application state information 434 includes data thatdescribes a state of the native application after the user device 200has performed the one or more operations indicated in the accessinformation 202. In a specific example, if the card record 430 isassociated with a shopping application, the application stateinformation 434 includes data that describes products (e.g., names andprices) that are shown when the shopping application is set to theapplication state specified by the access information 202. As anotherexample, if the card record 430 is associated with a music playerapplication, the application state information 434 includes data thatdescribes a song (e.g., name and artist) that is played when the musicplayer application is set to the application state specified by theaccess information 202.

The types of data included in the application state information 434 maydepend on the type of information associated with the application statespecified by the access information 202. For example, if the card record430 is for an application that provides reviews of restaurants, theapplication state information 434 includes information (e.g., text andnumbers) related to a restaurant, such as a category of the restaurant,reviews of the restaurant, and a menu for the restaurant. In thisexample, the access information 202 causes the application (e.g., anative application or a web-browser application) to launch and retrieveinformation relating to the restaurant. As another example, if the cardrecord 430 is for an application that plays music, the application stateinformation 434 may include information relating to a song, such as thename of the song, the artist, the lyrics, and listener reviews. In thisexample, the access information 202 causes the application to launch andplay the song described in the application state information 434.

The application card ID 432 may be used to identify a native applicationassociated with the card record 430. The application card ID 43 may be astring of alphabetic, numeric, and/or symbolic characters (e.g.,punctuation marks) that uniquely identifies the associated nativeapplication. In some examples, the application card ID 43 is the nativeapplication in human readable form. For example, the application card ID43 may include the name of the application referenced in the accessinformation 202. In some examples, the application card ID 43 for arestaurant finder application includes the name of the restaurant finderapplication.

As another example, the card record 430 may be associated with theOPENTABLE® application, developed by OpenTable®, Inc. The OPENTABLE®application is a restaurant-reservation application that allows users tosearch for restaurants and make restaurant reservations. The OPENTABLE®application provides information about restaurants includingdescriptions of restaurants and user reviews of the restaurants. Theexample card record 430 may describe an application state of theOPENTABLE® application in which the OPENTABLE® application accessesinformation for THE FRENCH LAUNDRY® restaurant.

In other examples, the application card ID 432 includes a URL as aunique identifier for the card record 430. For example, the applicationcard ID 432 may include the string“func://www.yelp.com/biz/the-french-laundry-yountville-2?ob=1” as aunique identifier for the card record 430, or may include “func://” as anamespace, as described above.

The example application state information 434 includes data fields 435,such as a Title 435 a of THE FRENCH LAUNDRY® restaurant, a description435 b of THE FRENCH LAUNDRY® restaurant, image 435 c of THE FRENCHLAUNDRY® restaurant, and additional data fields 435. The title 435 afield may include, for example, the text “French cuisine” and“contemporary” and the title of the restaurant. The description field435 b may include text that describes THE FRENCH LAUNDRY® restaurant.The image 435 c may include text and/or an image of user reviews for THEFRENCH LAUNDRY® restaurant. The additional data fields 435 may includeadditional data for THE FRENCH LAUNDRY® restaurant that may notspecifically fit within the other defined fields, such as a menu for therestaurant, prices, and operating hours for the restaurant. In someimplementations, instructions for accessing the API 446 via informationfrom a remote API server 330 in order to obtain additional applicationstate information 434 are stored in the additional data fields 435 orthe access information 202 of the card record 430. There are manyformats that may be used to store and/or access the API 446, which maybe indicated in the additional data fields 435 or access information202. Any format acceptable to access the API 446 may be used. Forexample, the API 446 may be stored as a URL or FUNC:// type link inorder to access the web server 332. For example, instructions foraccessing the API server 330 may be stored as a URL.

The card record 430 includes one or more access information 202. Theaccess information 202 may include a reference to the OPENTABLE®application. As an example, the access information 202 for the cardrecord 430 may include a reference to the OPENTABLE® native applicationalong with one or more operations to be performed by the user device200. For example, the access information 202 may include an applicationresource identifier and/or one or more operations that cause the userdevice 200 to access the entry for THE FRENCH LAUNDRY® restaurant in theOPENTABLE® native application. An example application resourceidentifier may be“vnd.opentable.deeplink://opentable.com/restaurant/profile?rid=1180&refid=1.”

In some implementations, the access information 202 includes editioninformation that indicates the application edition with which the accessinformation 202 is compatible. For example, the edition informationindicates the operating system with which the access information 202 iscompatible. Moreover, different access information 202 may be associatedwith different editions of a native application. A native applicationedition (hereinafter “application edition”) refers to a particularimplementation or variation of a native application. For example, anapplication edition may refer to a version of a native application, suchas a version 1.0 of a native application or a version 2.0 of a nativeapplication. In another example, an application edition may refer to animplementation of a native application for a specific platform, such asa specific operating system.

The different access information included in a card record may cause thecorresponding application editions to launch and perform similarfunctions. Accordingly, the different access information included in acard record may cause the corresponding application editions to be setinto similar application states. For example, if the different accessinformation reference different editions of an information retrievalapplication, the different access information may cause thecorresponding application editions to retrieve similar information. Inanother example, if the different access information reference differenteditions of an internet music player application, the different accessinformation may cause the corresponding application editions to play thesame song.

In some examples, a card record for a native application that retrievesrestaurant information includes multiple different application accessinformation for multiple different application editions. As an example,if the card record is associated with a specific Mexican restaurant, theapplication access information for the different application editionsmay cause each application edition to retrieve information for the samespecific Mexican restaurant. For example, first application accessinformation may cause a first application edition (e.g., on a firstoperating system) to retrieve information for the specific Mexicanrestaurant. Second application access information may cause a secondapplication edition (e.g., on a second operating system) to retrieveinformation for the specific Mexican restaurant.

FIG. 5 shows an example of the user device 200 including a user deviceprocessor 270 in communication with memory 280, a network interface 282,user interface devices 284 and/or display 206. The network interface 282may include a media access control (MAC) module 290 and a physical layer(PHY) module 292, which communicates with other user devices, servers,networks, network devices etc. disclosed herein. The user device 200 mayinclude other components as well. The user device processor 270 isconfigured to execute instructions stored in the memory 280 that whenexecuted cause the user device processor 270 to perform operations. Insome examples, the user device processor 270 executes one or more of anative application 210, a web browser application 211, and an operatingsystem 216, all of which may be embodied as computer readableinstructions. The operating system 216 may act as an interface betweenthe user device processor 270 and the applications.

In some implementations, the user device processor 270 executes anapplication. The application is a set of computer readable instructionsembedded in a native application. In the example shown, the user deviceprocessor 270 executes the sharing module 410, which may be stored inthe memory 280. In other examples, the memory 280 is located remotelyfrom the user device 200 and/or the sharing module 410.

The memory 280 may store programs (e.g., sequences of instructions) ordata (e.g., program state information) on a temporary or permanent basisand perform as non-transitory memory for use by a computing device. Forexample, the memory 280 may store the computer readable instructionsthat make up the native applications 210, the web browser Apps 212, theoperating system 216, and/or the sharing module 410. The non-transitorymemory may be volatile and/or non-volatile addressable semiconductormemory. Examples of non-volatile memory include flash memory, read-onlymemory (ROM), programmable read-only memory (PROM), erasableprogrammable read-only memory (EPROM), electronically erasableprogrammable read-only memory (EEPROM) (e.g., typically used forfirmware, such as boot programs). Examples of volatile memory includerandom access memory (RAM), dynamic random access memory (DRAM), staticrandom access memory (SRAM), and phase change memory (PCM). The networkinterface 282 includes one or more devices configured to communicatewith the distributed network 120.

The network interface 282 may include one or more transceivers forperforming wired or wireless communication. Examples of the networkinterface 282 include a transceiver configured to perform communicationsusing the IEEE 802.11 wireless standard, an Ethernet port, a wirelesstransmitter, and a universal serial bus (USB) port. The user interfacedevices 284 include one or more devices that receive input from and/orprovide output to a user 10. The user interface devices 284 may includea touchscreen, a display, a QWERTY keyboard or other keyboard, a numerickeypad, a touchpad, a microphone, and/or speakers.

FIG. 6 shows an example of the sharing server 400. The sharing server400 includes a server processor 402, memory 420 and a network interface502. The server processor 402 may include the sharing module 410 and/ora resolver module 440. The memory 420 stores the templates 422, userrecords 424, configuration data 426, and card records 430. The networkinterface 502 includes a PHY module 506 and a MAC module 508. The PHYmodule 506 communicates with the networks, network devices, userdevices, and/or servers disclosed herein.

FIG. 7 shows an example computing device 600 that may be used toimplement the systems and methods described in this document. Thecomputing device 600 may be structurally representative of one or moreof the user devices and/or servers disclosed herein. The computingdevice 600 may be a digital computer, such as a laptop, a desktop, aworkstation, a personal digital assistant, a server, a blade server, amainframe, or other appropriate computer. The components shown,connections, relationships between components, and correspondingfunctions are meant to be exemplary only, and are not meant to limitimplementations of the disclosures described and/or claimed in thisdocument.

The computing device 600 includes a processor 610, a memory 620, astorage device 630, a high-speed interface/controller 640, high-speedexpansion ports 650, a low speed interface/controller 660, and aninterface 675. The low speed interface/controller 660 is connected tolow speed bus 670 and storage device 630. Each of the components 610,620, 630, 640, 650, 660, 675 are interconnected using various busses,and may be mounted on a common motherboard or in other manners asappropriate. The processor 610 can process instructions for executionwithin the computing device 600, including instructions stored in thememory 620 or on the storage device 630 to display graphical informationfor a graphical user interface (GUI) on an external input/output device(e.g., the display 680 coupled to high speed interface 640). In otherimplementations, multiple processors and/or multiple buses may be used,as appropriate, along with multiple memories and types of memory. Also,multiple computing devices 600 may be connected, with each deviceproviding portions of the implemented operations (e.g., connected as aserver bank, a group of blade servers, or a multi-processor system).

The memory 620 stores information non-transitorily within the computingdevice 600. The memory 620 may include computer-readable medium,volatile memory or non-volatile memory. The non-transitory memory 620may store programs (e.g., sequences of instructions) or data (e.g.,program state information) on a temporary or permanent basis for use bythe computing device 600.

The storage device 630 is capable of providing mass storage for thecomputing device 600. In some implementations, the storage device 630 isa computer-readable medium. In various different implementations, thestorage device 630 includes a floppy disk device, a hard disk device, anoptical disk device, a tape device, a flash memory and/or other similarsolid state memory device. The storage device 630 may include an arrayof devices, such as devices in a storage area network and/or in otherconfigurations. In additional implementations, a computer programproduct is tangibly embodied in an information carrier. The computerprogram product includes instructions that, when executed, perform oneor more methods, such as those described above. The information carrieris a computer or machine-readable medium, such as the memory 620, thestorage device 630, or memory on processor 610.

The high-speed controller 640 manages bandwidth-intensive operations forthe computing device 600, while the low-speed controller 660 manageslower bandwidth-intensive operations. Such allocation of duties isexemplary only. In some implementations, the high-speed controller 640is coupled to the memory 620, the display 680 (e.g., through a graphicsprocessor or accelerator), and to the high-speed expansion ports 650,which accepts various expansion cards (not shown). In someimplementations, the low-speed controller 660 is coupled to the storagedevice 630 and low-speed expansion port 670. The low-speed expansionport 670, which may include various communication ports (e.g., USB,Bluetooth, Ethernet, wireless Ethernet), may be coupled to one or moreinput/output devices, such as a keyboard, a pointing device, a scanner,or a networking device, such as a switch or router, e.g., through anetwork adapter.

The computing device 600 may be implemented in a number of differentforms, as shown. For example, it may be implemented as a standard server600 a or multiple times in a group of such servers 600 a, as a laptopcomputer 600 b, or as part of a rack server system 600 c.

For further defined structure of the modules, processors, andcontrollers of FIGS. 1-3G and 6-7 see below provided methods of FIGS.8-13 and below provided definition for the term “module”. The systemsdisclosed herein may be operated using numerous methods, example methodsare illustrated in FIGS. 8-13. The methods of FIGS. 8-10 correspond toat least FIGS. 3A-3D. The methods of FIGS. 11-13 correspond to at leastFIGS. 3E-3G. Although the following methods are shown as separatemethods, one or more methods and/or operations from separate methods maybe combined and performed as a single method. For example, the method ofFIG. 8 may be performed while the methods of FIGS. 9-10 are performed.As another example, the method of FIG. 11 may be performed while themethods of FIGS. 12-13 are performed.

In FIG. 8, a method of sharing an application state between user devicesis shown. Although the following operations are primarily described withrespect to the implementations of FIGS. 8-10, the operations may applyto other implementations of the present disclosure. The operations maybe iteratively performed and/or performed in a different order thandescribed. The method may begin at 700. At 702, the user interfacedevice 284 or display 206 of the user device 200 a may receive a userinput corresponding to touching of the share button 222 to share a stateof an app currently executed and displayed on the first user device 200a. Each additional interaction between the user and the user device 200a with respect to the app may result in a new state of the app.

At 704, the sharing module 410 at the user device processor 270 maygenerate share and destination buttons and/or requests, which aredisplayed to a user of the first user device 200 a. At 706, the userinterface device 284 or display 206 of the first user device 200 a mayreceive user inputs indicating the share and destination selections asdescribed above with respect to FIG. 3A.

At 708, the sharing module 410 may determine app state and app stateinformation. This may include the sharing module via the networkinterface 282 sending a card record and/or app information request tothe sharing server 400 at 708A. At 708B, the sharing server 400 mayrespond and provide a card record and/or APP information back to thenetwork interface 282.

At 710, the sharing module 410 may generate a first data objectrepresentative of the state of the app based on the information receivedfrom the sharing server 400. This may include the information in thecard record including an ID of the second user device 200 b. The firstdata object includes information to recreate the app state in the seconduser device 200 b. The first data object includes a card recordassociated with the app state and access information having a referenceto the application and indicating a performable operation for theapplication to enter an operating state providing information from thecard record. The first data object may also include additional datarelating to the user of the first user device 200 a, the operatingsystem 216, configuration files, screen formatting, display type,display size, and/or display configuration data.

At 712, the sharing module 410 may generate and display a cardcorresponding to the app state. The API 446 or SDK 444 includes thefunctions and instructions to convert the first data object into a cardthat can be displayed by the first user device 200 a. The card includesthe information from the card record. The card record may includeadditional information including the application card ID 432,application state information 434, access information 202, and templateID 436.

In some implementations, when the card includes a user-selectable linkassociated with the access information 202, the method includesreceiving, at the user device processor 270, a user input for selectionof the user selectable link and executes a sharing application based onthe access information 202 associated with the selected user selectablelink. The user 10 selection may include at least one of a voice command,a touch gesture, or a click selection.

When the card includes a user selectable link associated with the accessinformation 202, the method may include receiving, at the user deviceprocessor 270, a user selection of the user selectable link anddisplaying a representation of the app state of the application executedon the second user device 200 b. This may occur without executing theapplication on the second user device 200 b. The method may furtherinclude populating the card and/or corresponding template with theinformation from the card record based on at least one of a type of thefirst user device 200 a, an operating system of the first user device200 a, a type of the first data object, or a type of the user of thefirst user device 200 a. The type of the first user device 200 a mayinclude the characteristics of the first user device 200 a, such aswhether the first user device 200 a is a phone, tablet, media player,desktop, or laptop and whether the generation, manufacturer, and orversion of the first user device 200 a. The operating system type may berepresentative of the respective operating system 216 or the currentapplication running on the first user device 200 a. The user type mayinclude characteristics of the user including a location, IP address,preferences, accounts, physical characteristics and or collected dataregarding the user. The method may also include sending the first dataobject from the first user device 200 a to a third user deviceassociated with a third user. The first data object may include displayconfiguration data. The display configuration data may includeinformation on (i) how the API 446 or SDK 444 instructs the first userdevice 200 a to display the first data object, or (ii) functions thatare not implemented by the first user device 200 a and second userdevice 200 b.

At 714, the sharing module 410 may determine whether the card is to bemodified. This may be based on a user input indicating that the card bemodified. If the card is to be modified, task 715 may be performed;otherwise task 716 may be performed. At 715, the app state may bemodified due to interaction with the user. At 716, the sharing module410 may send the first data object via the network interface 282 to thesecond user device 200 b. The first data object may be initiated andsent to the second user device 200 b and/or the sharing server 400 usinga user selectable link. The method may end at 718.

FIG. 9 shows a method of providing a card record and a template from asharing server to user devices 200 a, 200 b. Although the followingoperations are primarily described with respect to the implementationsof FIGS. 8-10, the operations may apply to other implementations of thepresent disclosure. The operations may be iteratively performed and/orperformed in a different order than described. The method may begin at800. At 802, the sharing server 400 via the network interface 502receives the card record and/or app information request from the firstuser device 200 a for the app state of the first user device 200 a.

At 804, the sharing module 410 of the server processor 402 of thesharing server 400 searches for a card record and/or app informationbased on the information in the card record and/or app informationrequest. At 806, the sharing module 410 of the sharing server 400 maydetermine compatibility of the second user device 200 b for the app asdescribed above. The sharing module 410 determines a compatibility typeof the second user device 200 b based on the identification of thesecond user device 200 b. The sharing server 400 may access the memory420 to determine the compatibility type of the second user device 200 b.The memory 420 includes templates 422, user records 424, configurationdata 426, and card records 430 for determining the compatibility type.In some implementations, determining the compatibility type of thesecond user device 200 b includes searching a data source or memory 420for compatibility information based on the identification of the seconduser device 200 b. Operation 806 may account for when the platforms ofthe first user device 200 a and the second user device 200 b are thesame or different and/or whether the first user device 200 a and thesecond user device 200 b have the same or different SDK. Operation 806may also account for whether the user devices 200 a, 200 b are capableof executing the same application and/or versions of the sameapplication.

At 808, the sharing module 410 may modify and/or transmit the cardrecord based on the determined compatibility at 806 to the first userdevice 200 a.

At 810, the network interface 502 may receive the first data object fromthe first user device 200 a or from the second user device 200 b. Thesharing server 400 is configured to receive the first data object viathe distributed network 120. The first data object may include the ID ofthe second user device 200 b.

At 812, the sharing module 410 determines whether the first data objectis to be formatted. If the first data object is to be formatted, task814 is performed. For example, if the second user device 200 b is unableto execute and display the app state based on the information providedin the first data object and/or is unable to execute the same version ofthe application corresponding to the app state, then the first dataobject is formatted. If the first data object is not formatted, thentask 816 is performed.

At 814, the sharing module 410 of the sharing server 400 may format thefirst data object to create a second data object that is compatible withthe second user device 200 b. The sharing server 400 may use informationin the memory 420 including templates 422, user records 424,configuration data 426, access information, and card records 430 toconvert the first data object to the second data object and ensurecompatibility with the second user device 200 b. The sharing module 410may reference the memory 420 to determine how to format the first dataobject to the second data object or find a suitable substitute functionthat performs the same function as the first data object and replace thefirst data object with the second data object.

The second data object includes a card record 430 associated with theapp state and access information 202 having a reference to theapplication and indicating a performable operation for the applicationto enter an operating state providing information from the card record430. The second data object allows the second user device 200 b to openthe application referenced in the first data object to the same state asthe app state that generated that first data object.

The access information is formatted based on the compatibility type ofthe second user device 200 b. The sharing server 400 is able to convertthe access information to an appropriate format that is compatible withthe second user device 200 b by reference to the memory 420. The firstdata object may be formatted to be displayed as a card. In someexamples, the method includes populating a template with the informationfrom the card record 430 and based on at least one of the type of thefirst user device 200 a, the operating system of the first user device200 a, the data object type, or the user type.

At 816, the sharing module 410 may select a template using a thresholdfit process. The sharing module 410 may threshold fit the first dataobject and/or the second data object to stored templates and/or based ontemplate ID in card record information. The template that best matchesor corresponds with the first data object or the second data object isselected. The second data object includes the card record and the accessinformation, where the access information has a reference to theapplication executed on the first user device 200 a and indicates anoperation for a version of the application to enter the state, and wherethe access information is formatted based on the compatibility type ofthe second user device 200 b. At 818, the second data object and/or thetemplate are transmitted to the second user device 200 b. The method mayend at 820.

FIG. 10 shows a method of modifying and/or formatting and rendering theapp state of the first user device 200 a at the second user device 200b. Although the following operations are primarily described withrespect to the implementations of FIGS. 8-10, the operations may applyto other implementations of the present disclosure. The operations maybe iteratively performed and/or performed in a different order thandescribed. The method may begin at 900. At 902, the network interface282 of the second user device 200 b receives a first data object fromthe first user device 200 a or the sharing server 400. The first dataobject is representative of the app state at the first user device 200a.

At 904, the sharing module 410 of the second user device 200 bdetermines whether to modify app state information of the first dataobject. This may include determining whether the app state informationis static or dynamic. If the sharing module 410 of the second userdevice 200 b determines that the first data object is incompatible orunable to be properly displayed, the second user device 200 b may sendthe first data object to the sharing server 400 for translation of thefirst data object into a compatible data object. If the app stateinformation is static and/or is not to be modified task 906 isperformed, otherwise task 910 is performed.

At 905, the sharing module 410 of the second user device 200 b may senda request signal to the sharing server 400 for the first template. At906, the sharing module 410 of the second user device 200 b receives thefirst template provided at 818 for the first data object from thesharing server 400. At 907, the sharing module 410 of the second userdevice 200 b may generate the card for the app state.

At 908, the sharing module 410 executes the app and/or displays on thedisplay 206 of the second user device 200 b the app state, the cardcorresponding to the app state, app information corresponding to the appstate. This is based on (i) information in the first data objectincluding information from the accessed card record, and (ii) data inthe first template.

At 909, the sharing module 410 of the second user device 200 b may senda request signal to the sharing server 400 for the second template. At910, the sharing module 410 modifies and/or has the app stateinformation of the first data object modified. This may include thesharing module 410 sending the first data object to the sharing server400 at 910A. At 910B, the sharing module 410 may receive the second dataobject generated at 814 and transmitted from the sharing server 400 at818.

At 912, the sharing module 410 may receive a second template for thesecond data object transmitted at 818. At 913, the sharing module 410 ofthe second user device 200 b may generate the card for the updated appstate or a second version of the app state.

At 914, the sharing module 410 (i) executes an app compatible with thesecond user device 200 b and corresponding to the app executed on thefirst user device 200 a, and/or (ii) displays on the display 206 of thesecond user device 200 b a compatible app state corresponding to the appstate of the first user device 200 a, the card corresponding to thecompatible app state, app information corresponding to the compatibleapp state. This is based on (i) information in the second data objectincluding information from the corresponding accessed card record, and(ii) data in the second template. The method may end at 916.

For operations 908 and 914, the API 446 and SDK 444 include thefunctions and information to display the card on the display 206. Thecard may be displayed in a dedicated application or inside an alreadyrunning application. The card may include the information from the cardrecord 430. When the card includes a user selectable link associatedwith the access information 202, the method may include receiving a userselection of the user selectable link and displaying a representation ofthe app state executable on the second user device 200 b withoutexecuting the application. The method may further include populatingtemplate 422 with the information from the card record 430 based on atleast one of the type of the first user device 200 a, the operatingsystem of the first user device 200 a, the data object type, and/or theuser type. The method may also include sending the first data object orthe second data object from the second user device 200 b to a third userdevice. The second data object may include display configuration dataincluding information on how the API 446 or SDK 444 instructs the seconduser device 200 b to display the first data object or the second dataobject or functions not performed by the first user device 200 a andsecond user device 200 b.

FIG. 11 shows a method of sharing a card and/or an app state betweenuser devices 200 a, 200 b. Although the following operations areprimarily described with respect to the implementations of FIGS. 11-13,the operations may apply to other implementations of the presentdisclosure. The operations may be iteratively performed and/or performedin a different order than described. The method may begin at 1000. At1002, the user interface device 284 or display 206 of the user device200 a may receive a user input corresponding to touching of the sharebutton 222 to share a state of an app currently executed and displayedon the first user device 200 a or a card corresponding to the state ofthe app. A user selectable link associated with the selected card isused to identify the app state to be shared. The app state includesinformation such as images and text corresponding to information storedin a card record. The card may include information such as images andtext corresponding to information displayed in the app state. The cardmay be selectable by the user in order to launch the application and setthe application in the state represented by the card based on accessinformation 202.

At 1004, the sharing module 410 of the first user device 200 a maydetermine the state of the app and/or app state information. At 1006,the sharing module 410 of the first user device 200 a (or the sharingmodule of the sharing server 400) may generate one or more data objectsrepresentative of the card and/or the app state based on the informationdetermined at 1004. If the data objects are generated at the sharingserver 400, the state of the app and/or the app state information may betransmitted to the haring server 400 and the sharing server 400 mayreturn the data objects.

The sharing module 410 of the first user device 200 a selectsinformation from the card to create data object(s) for transfer to thereceiving user device 200 b. Information elements may be selected basedupon information selection rules and a selected method of transmission.For example, the card may be rendered using a particular template, whichmay include image 435 c with a tag “main image,” and description 435 bwith a tag “description.” In this example, an information selection rulemay indicate that a first data object may include an image tagged as“main image,” and second data object may include text tagged as“description.” Moreover, the selected method of transmission may becompatible with image messages. Accordingly, the sharing module 410creates data object(s) containing image 435 c and description 435 b fortransmission to receiving user device 200 b. Furthermore, the sharingmodule 410 may select a resolver URL 438 associated with the card fortransmission as a third data object. In some embodiments, the sharingmodule 410 of device 200 a may retrieve additional information fromsharing server 400 in order to create data objects for transmission.

The sharing module 410 integrated with a native application displayingthe app state may extract information from the app state in order tocreate data object(s). In one embodiment, the sharing module 410captures a screenshot of all or part of the displayed app state. Thesharing module 410 may also communicate with sharing server 400 toretrieve additional information in order to create data object(s). Inparticular, sharing module 410 may send a query containing informationabout the app state to the sharing server 400.

At 1008, the sharing module 410 of the first user device 200 a maygenerate share and destination requests, which are displayed to a userof the first user device 200 a. As part of the selection process, thefirst user device 200 a may display menus for the user to select aparticular messaging application for sharing the card and/or app stateand a second user to receive the shared card and/or app state.

At 1010, the user interface device 284 or display 206 of the first userdevice 200 a may receive user inputs indicating the share anddestination selections as described above with respect to FIG. 3A. Theshare selection indicates the method of transmission selected by theuser of the first user device 200 a.

At 1012, the sharing module 410 of the first user device 200 a or of thesharing server 400 formats the data object(s) to generate one or moremessages based on the method of transmission selected by the user of thefirst user device 200 a. If the sharing module 410 of the sharing server400 performs this operation, then the data objects may be transmitted tothe sharing server 400 and the sharing server 400 transmits back the oneor more messages to the first user device 200 a. A user may haveselected the method of transmission at 1010 or a default method oftransmission may be selected. The one or messages may include a resolverURL (e.g., the resolver URL 438). As an example, when a user selects atext messaging transmission method (e.g., an SMS service), the dataobjects may be formatted into short messages. Formatting may includesplitting long text strings into separate messages, concatenating shorttext strings into a single message, formatting images into multimediamessaging service (MMS) messages, and the like. As another example, whena user selects an email messaging service, processing may includeautomatic creation of a subject line, rendering of information usingmarkup language, and the like. The sharing module 410 of the first userdevice 200 a may execute formatting according to information selectionrules.

At 1014, the network interface 282 transmits the one or more messages tothe second user device using the selected method of transmission. Theformatted data objects are sent as messages (e.g., messages 224) to thespecified received user device 220 b. The sharing module 410 may send amessage to the selected messaging application (e.g., one of applications210) indicating the receiving user device 200 b and the content of dataobjects to be sent as messages 224. The method may end at 1016.

FIG. 12 shows a method of creating a card via a sharing module. Althoughthe following operations are primarily described with respect to theimplementations of FIGS. 11-13, the operations may apply to otherimplementations of the present disclosure. The operations may beiteratively performed and/or performed in a different order thandescribed. The method may begin at 1100. At 1102, the network interface502 of the sharing server 400 receives a HTTP request from the seconduser device 200 b including a user agent string, a query, a resolverURL, an operating system ID, a rendering method, an indication ofwhether the sharing module 410 is installed at the second user device200 b, etc. The HTTP request may be from the web browser application 211running on the second user device 200 b. The selected applicationaccesses the sharing server 400 using the resolver URL. When theselected application is a web browser application, it may access a webserver run by the resolver module 440 using the resolver URL.

At 1104, the resolver module 440 searches for a card record matching thereceived resolver URL, a template for rendering the card, andconfiguration data. The resolver module 440 at the sharing server 400may search for the card record matching the app state and sendinformation elements back to sharing module 410. The resolver module 440and/or sharing module 410 may select information elements based uponinformation selection rules and a selected method of transmission. Forexample, card record 430 may include description information 435 b andimage information 435 c. In this example, an information selection rulemay indicate that a first data object should include an image and asecond data object should include description text. Moreover, theselected method of transmission may be compatible with image messages.Accordingly, the sharing module 410 creates data object(s) 320containing image 435 c and description 435 b for transmission toreceiving device 200 b. Furthermore, the sharing module 410 may select aresolver URL 438 for transmission, for example, as a third data object.

The resolver module 440 finds a card record matching the receivedresolver URL, a template for rendering a card that matches the templateidentifier of the card record, and configuration data for a templatewith the given template identifier. When the resolver module 440responds to a web browser application, the resolver module 440 mayselect a web template. When the resolver module 440 responds to a nativeapplication, the resolver module 440 may select a template for thespecified operating system, unless the rendering method is a webrendering method.

At 1106, the sharing module 410 or the resolver module 440 at thesharing server 400 may populate a template with data from the cardrecord according to the configuration data. At 1108, the resolver module440 at the sharing server 400 configures a link (e.g., HTTP link) forthe card. The resolver module 440 may select access information toconfigure a link for the card. The access information may be selectedbased on the application that will display the card, the operatingsystem, and/or whether the application is installed. In someembodiments, the resolver module 440 selects web access information toconfigure a link for a web card. In these or other embodiments, theresolver module 440 may select application access information if theoperating system is known and the corresponding application isinstalled. In alternate embodiments, the resolver module 440 selectsapplication access information based on the operating system specifiedby the user agent string.

At 1110, the sharing module 410 at the sharing server 400 creates thecard based on the template and the configured link to the card. At 1112,the network interface 502 transmits the card to the second user device.After populating template to create the card, the resolver module 440sends the card back to the receiving user device 200 b, where the cardis rendered for display in the selected application. The method may endat 1114.

FIG. 13 shows a method of rendering a card at the second user device 200b based on message received from the first user device. Although thefollowing operations are primarily described with respect to theimplementations of FIGS. 11-13, the operations may apply to otherimplementations of the present disclosure. The operations may beiteratively performed and/or performed in a different order thandescribed. The method may begin at 1200. At 1202, the network interface282 at the second user device 200 b receives the one or more messagestransmitted at 1014. The message(s) correspond to a state of the app atthe first user device 200 a. A user of receiving device may openmessaging application 210 and view the messages. Messages may includeimages and/or text representing the app state shared by the sending userdevice 200 a. One of the messages may include the resolver URL 438,which may be formatted as a selectable link.

At 1204, the user interface devices 284 or display 206 receives an inputfrom a user selecting a link for access information and/or the resolverURL. The user of the receiving device 200 b may select the linkincluding resolver URL 438.

At 1206, the URL handling module 448 selects an app for rendering a cardcorresponding to the app state of the first user device 200 a. The URLhandling module 448 determines which application should intercept andreceive the resolver URL. If a sharing module 410 is not installed atreceiving user device 200 b (e.g., if no applications 210 installed atreceiving user device 200 b include an integrated sharing applicationand/or the receiving user device 200 b does not include the sharingmodule 410 module 410), a web browser application may be specified bythe URL handler module 448. If a sharing module 410 is installed at thereceiving user device 200 b, an application including a sharingapplication that operates similar to the sharing module 410 may beselected to receive the resolver URL.

At 1208, the user device processor 270 of the second user device 200 bexecutes the app selected at 1206. As an example, the selected app maybe a web browser app. If the access information is web accessinformation, the browser application 211 may handle the accessinformation by accessing a web page specified by the web accessinformation that corresponds to the app state. If the access informationis application access information, a native application 210 may handlethe access information by accessing the app state.

At 1210, the user device processor 270 of the second user device 200 btransmits the HTTP request for the card to the sharing server 400 or webserver 312 based on the resolver URL. The selected application accessesthe sharing server 400 using the resolver URL. When the selectedapplication is a web browser application, the selected application mayaccess a web server run by the resolver module 440 using the resolverURL.

At 1212, the sharing module 410 of the second user device 200 b receivesthe card, including the link configured at 1108, from sharing server 400or the web server 312. At 1214, the sharing module 410 of the seconduser device 200 b displays the card on the display 206 of the seconduser device 200 b.

At 1216, the user interface devices 284 or the display 206 receives auser input selecting the card/link. This may cause the processor of thesecond user device 200 b to request that the sharing server convert thelink to another (or deep) link and launch a search engine results page(SERP) within the app. At 1218, the sharing module 410 displays the appstate corresponding to the app state shared by the first user device 200a. The method may end at 1220.

The above-described operations of FIGS. 8-13 are meant to beillustrative examples; the operations may be performed sequentially,synchronously, simultaneously, continuously, during overlapping timeperiods or in a different order depending upon the application. Also,any of the operations may not be performed or skipped depending on theimplementation and/or sequence of events.

As another example, a card is shared from a device A (origin device) toa device B (destination device). The underlining assumption in thisexample is that the app on device A used to share cards is integratedwith a SDK, and the SDK has the ability of working with links andsupplying cards. The platforms of devices A and B may be an Android®platform, an iOS® platform or a tablet platform.

In other examples, a generic app in device A is integrated with SDK isshared with device B. A user A of device A and while running the genericapp clicks a “Share” button, such that a list of options on how to shareis displayed. The list of options asks user A “Do you want to share thiscard via, for instance, Messenger, Hangout, email, Bluetooth®, . . . ?”Assuming user A decides to choose Hangout to share the card with user Bof device B, then user A chooses to whom he/she wants to share the card.A list of user A's Hangout friends/contact list is displayed and user Bis included in this list. Once user A chooses user B and clicks “Send”button, the actions of “share a card” on device A are completed.

Now on device B, several situations can occur: 1) device B has the sameplatform as device A and device B is also installed with Hangout, andthe generic app in device B is SDK integrated; 2) device B has adifferent platform than device A, although device B also has Hangoutinstalled and the generic app is SDK integrated; 3) device B has a sameor different platform as device A and none of Apps in device B is SDKintegrated; 4) device B has a same or different platform as device A andsome other App(s) other than the generic app in device B are SDKintegrated; 5) besides above 4 situations, device A and B can both havea Launch app installed and devices A and B directly share cards via theLaunch app.

In other examples, the devices A and B have a same platform, a same appand are integrated with SDK. In this situation, a lot of capabilitiesexist that may be shared between the two users. In the generic app ondevice A, there is the sharing function, where SDK may package anddeploy a data object. When that data reaches device B, the data objectsupplies the data to SDK, which is inside the generic app on device B.The SDK on device B receives, interprets and displays the data.

In other examples, devices A and B have different platforms, a same app,and are both integrated with SDK. As along as the SDKs are built forAndroid®, iOS® or other platforms and can understand the data exchange,the same method can be used across platforms. If the SDKs render theJSON binary large object (blob) on both platforms, then the devices Aand B may send the JSON blob data across platforms. The job of the SDKsis to translate the custom formatting to a local object that devices canrender in a view.

In other examples, device B has no app integrated with SDK. In thiscase, to send or share cards as a text message, a simplest version thatmay be sent is to pass the URL of the particular card. On device B, someof the messenger Apps have capabilities to display images. If the dataobject is sent to these messenger Apps, the messenger Apps take care ofimage rendering automatically, like a JPEG. For some other messengerApps, if a link is received that is an image, rendering occursautomatically.

The cards may be shared in an image format or a text format. The cardsmay also be shared via emails by being linked to the email app afterclicking the share button. The email app may prepare a subject line, anduser A can enter the image, as well as the http link. For instance, ifthe http link is http://quixey.com/ . . . , then if user B clicks onthat link once received, device B access the servers that convert thathttp link and launches SERPs within the corresponding app.

In other examples, the online resolver is used and then the card isdisplayed in a browser, not inside the messaging app, but in the webbrowser itself. A web SDK may not be used because of standard htmlfiles. The online resolver figures out the configurations and thendisplays cards in the browser window.

In other examples, the generic app in device B is not SDK integrated,however other Apps (e.g., Yelp) are SDK integrated. In this case, deviceB receives a link in Hangout, http://quixey.io/ . . . and user B clickson this link. SDK in device B, although integrated with Yelp, detectsthe click and then handles the interaction locally and launches the appstate. Basically, SDK registers for listening on http://quixey.io/ . . .. For any request that comes to that URL, SDK provides the prompt “Whatdo you want to do with it?” User B may have a choice to view the cardvia the web service or via a locally listening service. Both devices Aand B have SDK integrated Apps installed. Instead of sharing an httplink, a quxiey:// . . . protocol link is also available. This type oflink can be directly intercepted by SDK, such that the users do not getquestions like “choose from these two options”. SDK can directly link tothe app state. For each app, the link is written as Quixey:// . . .followed by the software product ID. Each app has a unique softwareproduct ID, such that the app detects only the Apps broadcast, e.g. FBcan only listen to the shared FB cards, and generic app may only detect(or listen) the shared generic app cards. As a result, there is nocompeting listener.

In other examples, both devices A and B have a Launch app installed.Inside any app, if a user clicks the “share” button, the user will needto choose from a list of options on how to share, such as viaBluetooth®, message Apps, etc. The Launch app may be one of the optionsto share the state of the app. Similar to sharing via Hangout, forexample, choosing to share via the Launch app, the user is asked “Whomdo you want to send it to?” A list of suggested destinations may also beprovided, i.e. the contacts/friends with user device that also have theLaunch app installed. Once the user chooses the destination, the Launchapp shares the card to the destination.

In other example, the Launch app has the SDK installed. The Launch appintercepts the message and can display the cards. The Launch app may beassociated with a search provider account (e.g., a Google® account);such that the Launch app account identity is linked to the searchprovider account (i.e. the search provider account is reused as theidentifier for the Launch App).

The Launch app installed on device B may show a card, maybe showing anotification bar/pop-up on a home screen. Then user B can click on thecard, such that the app may enter the state and be a seamlessexperience: SDK may directly transition to the app state without showinga card notification. For example, a generic app card may be shared via aLaunch app. On device B, SDK launches the state within generic appdirectly.

For a seamless experience method, a user via a user device may directlyinvoke the app state. If a user logs in a browser in both a desktop andphone, the card may be shared between the two devices. For example, ondesktop, the user shares a Google® map with his/her phone: “send thisdirection to my phone”. Then on the phone, the user starts seeing thedirection. The user does not need to be first shown a card, click thecard and then see the direction. A another example, if a user sends alink: Quixey.io/furl=uberpickuptime, instead of displaying the card ofUber and the pick-up times, SDK may directly invoke Uber® and show userB the pick-up times directly. It is one step further than displaying thecard.

In other examples and for the pop-up method, there may be a cards feed,such that users may not only share cards to a particular user, but canalso share to a group. Whoever subscribes to the group, users can seethe updates shown up in the feed.

In other examples, the data object may include a data blob of JSON,which SDK receives from an API server directly. The data object is onepiece of JSON and only SDK is able to interpret the data object. Thedata object does not include layout information directly. The dataobject includes data including configuration data and/or a function URL.The data is to be shown in the appropriate places in the user interface(UI). The configuration provides information about how the UI elementsneed to be structured including the capability to configure thetemplate. The function URL uniquely identifies the card. An example of afunction URL is furl://yelp.com/ . . . .

Each JSON blob has data. The data, for example for the generic app,includes ranking data, description data, image data, image URL data,etc. In case of different platforms, the JSON blob from an Android®platform sends data to an iOS® platform. The SDK in the iOS® platformknows the UI elements in the cards and information for mapping the data,such that: the image data is mapped to the appropriate image icon; acorresponding title is mapped to a displayed top section, and so on.This information of the layout of the UI elements may be stored as astandardized template and is available to the SDK. The information maybe downloaded as required from one or more of the servers disclosedherein.

In other examples, the standardized template (or other templatedisclosed herein) is stored on one of the servers and/or in memory(e.g., cache) of a target device. If the template is not stored on thetarget device, the device, via the SDK, makes a call to the appropriateserver. The template is then downloaded from the server to the targetdevice. Different templates may be used for differentsituations/conditions. The templates may be generated based onspecifications for items, such as place, product, creative work, etc.Each of these specifications has different kinds of elements. Forexample, a “place” would include information, such as an address, aphone number, open hours of business, etc. This information does notnecessarily apply to a “product” situation. A thin template just has atitle, an image field and a description section. A thick (or morespecific) template includes addition information.

A template may not be fixed, may be changed, and/or may have customfeatures. The templates may be configurable. A template may haveinformation to customize: the size of an image; color of text; and allowfor certain sections of text to include text and/or backgrounds withdifferent color. For example, a displayed rating of above apredetermined amount for a certain game (e.g., Foursquare) may have agreen color background. For Groupon, in a deal section, a current pricemay be displayed, which may be bold and highlighted in green, whereas aprevious value may have a strike through the number and not have a greenbackground.

In other examples, a simple template may display an image in apredetermined location and a title and description corresponding to theimage. In this example, no control for color, size, and other specificsmay be provided. Default templates may be stored, used and/orcustomized. Layouts of the templates may be modified. For example, anEat24 template and a Yelp template may have a same default template, butthe actual templates used may provide different presentations in termsof, for example, number, size, shape and/or color of shown stars and/orother differences. As another example the generic app may use a greencircle for ratings while the Yelp app may use stars for ratings.

The configuration data disclosed herein may include a blob of data withconfiguration information for SDK. The configurations may map a contentelement or a data element into a layout element.

For different platforms, the layout of a UI of a user device may not beexchanged between user devices. However, in some examples, UIconfigurations may be exchanged between different platforms. This allowsboth platforms to understand the data being transferred between the userdevices. This prevents SDKs of the user devices from requesting dataobjects, cards, and/or other information to render an app state and/orcard.

In other examples, three template versions are stored depending on theplatforms, such as native templates for each of the Android® and iOSplatforms and a web template inside the web SDK. The templates may beacross platforms, but the actual implementation may be in a specificcode corresponding to the particular platform of the corresponding userdevice. The templates may have native layouts. A pre-defined set oftemplates may be stores and have default configurations for the nativelayouts. The configurations sent across platforms may include onlycontent and map to a layout or include special instructions. Forexample, a default image size may be 72×72, but a JSON blob may indicatedisplaying the image as 72×110.

The templates may have unique IDs for each layout element. For instance,an image field in the content from Yelp® may be called a “Thumb Nail”. Acode instruction may state insert “Thumb Nail” element from Yelp® in theimage layout element. The configurations may be specific to a functionURL and the corresponding function may be specific to an app. Aconfiguration file including configuration data may be stored for eachfunction. The configuration data may be the same or different acrossplatforms. An example difference may be: for this function, the templateID is called “product” template in Android®; but in iOS®, the templateID maybe called “products” template or “product 1” template. If a namecombination is correct across both platforms, then an entire instructionfile may be reused.

In other examples, when JSON is used, certain features may be turned ONand OFF based on key value pairs. For example, when sharing an app stateor card with device B, the configurations may disable a call button,because a data object may be sent from a mobile device (or device A) toa tablet device (device B) and a call is not appropriate. The SDK sendsthese/this configurations/logic in the JSON blob, which for instance,may instruct for this template a disable function call since the targetapp is on a tablet. The configuration/logic is different than actualexecuted Javascript® code. The configuration/logic may send featuresacross platforms based on one or more conditions. Flags may be turned ONand OFF at a rendering time, when the corresponding user device isdisplaying a view.

Various implementations of the systems and techniques described hereincan be realized in digital electronic and/or optical circuitry,integrated circuitry, specially designed ASICs (application specificintegrated circuits), computer hardware, firmware, software, and/orcombinations thereof. These various implementations can includeimplementation in one or more computer programs that are executableand/or interpretable on a programmable system including at least oneprogrammable processor, which may be special or general purpose, coupledto receive data and instructions from, and to transmit data andinstructions to, a storage system, at least one input device, and atleast one output device.

These computer programs (also known as programs, software, softwareapplications or code) include machine instructions for a programmableprocessor, and can be implemented in a high-level procedural and/orobject-oriented programming language, and/or in assembly/machinelanguage. As used herein, the terms “machine-readable medium” and“computer-readable medium” refer to any computer program product,non-transitory computer readable medium, apparatus and/or device (e.g.,magnetic discs, optical disks, memory, Programmable Logic Devices(PLDs)) used to provide machine instructions and/or data to aprogrammable processor, including a machine-readable medium thatreceives machine instructions as a machine-readable signal. The term“machine-readable signal” refers to any signal used to provide machineinstructions and/or data to a programmable processor.

The processes and logic flows described in this specification can beperformed by one or more programmable processors executing one or morecomputer programs to perform functions by operating on input data andgenerating output. The processes and logic flows can also be performedby special purpose logic circuitry, e.g., an FPGA (field programmablegate array) or an ASIC (application specific integrated circuit).Processors suitable for the execution of a computer program include, byway of example, both general and special purpose microprocessors, andany one or more processors of any kind of digital computer. Generally, aprocessor will receive instructions and data from a read only memory ora random access memory or both. The essential elements of a computer area processor for performing instructions and one or more memory devicesfor storing instructions and data. Generally, a computer will alsoinclude, or be operatively coupled to receive data from or transfer datato, or both, one or more mass storage devices for storing data, e.g.,magnetic, magneto optical disks, or optical disks. However, a computerneed not have such devices. Computer readable media suitable for storingcomputer program instructions and data include all forms of non-volatilememory, media and memory devices, including by way of examplesemiconductor memory devices, e.g., EPROM, EEPROM, and flash memorydevices; magnetic disks, e.g., internal hard disks or removable disks;magneto optical disks; and CD ROM and DVD-ROM disks. The processor andthe memory can be supplemented by, or incorporated in, special purposelogic circuitry.

To provide for interaction with a user, one or more aspects of thedisclosure can be implemented on a computer having a display device,e.g., a CRT (cathode ray tube), LCD (liquid crystal display) monitor, ortouch screen for displaying information to the user and optionally akeyboard and a pointing device, e.g., a mouse or a trackball, by whichthe user can provide input to the computer. Other kinds of devices canbe used to provide interaction with a user as well; for example,feedback provided to the user can be any form of sensory feedback, e.g.,visual feedback, auditory feedback, or tactile feedback; and input fromthe user can be received in any form, including acoustic, speech, ortactile input. In addition, a computer can interact with a user bysending documents to and receiving documents from a device that is usedby the user; for example, by sending web pages to a web browser on auser's client device in response to requests received from the webbrowser.

A number of implementations have been described. Nevertheless, it willbe understood that various modifications may be made without departingfrom the spirit and scope of the disclosure. Accordingly, otherimplementations are within the scope of the following claims. Forexample, the actions recited in the claims can be performed in adifferent order and still achieve desirable results.

The foregoing description is merely illustrative in nature and is in noway intended to limit the disclosure, its application, or uses. Thebroad teachings of the disclosure can be implemented in a variety offorms. Therefore, while this disclosure includes particular examples,the true scope of the disclosure should not be so limited since othermodifications will become apparent upon a study of the drawings, thespecification, and the following claims. It should be understood thatone or more steps within a method may be executed in different order (orconcurrently) without altering the principles of the present disclosure.Further, although each of the embodiments is described above as havingcertain features, any one or more of those features described withrespect to any embodiment of the disclosure can be implemented in and/orcombined with features of any of the other embodiments, even if thatcombination is not explicitly described. In other words, the describedembodiments are not mutually exclusive, and permutations of one or moreembodiments with one another remain within the scope of this disclosure.

Spatial and functional relationships between elements (for example,between modules) are described using various terms, including“connected,” “engaged,” “interfaced,” and “coupled.” Unless explicitlydescribed as being “direct,” when a relationship between first andsecond elements is described in the above disclosure, that relationshipencompasses a direct relationship where no other intervening elementsare present between the first and second elements, and also an indirectrelationship where one or more intervening elements are present (eitherspatially or functionally) between the first and second elements. Asused herein, the phrase at least one of A, B, and C should be construedto mean a logical (A OR B OR C), using a non-exclusive logical OR, andshould not be construed to mean “at least one of A, at least one of B,and at least one of C.”

In the figures, the direction of an arrow, as indicated by thearrowhead, generally demonstrates the flow of information (such as dataor instructions) that is of interest to the illustration. For example,when element A and element B exchange a variety of information butinformation transmitted from element A to element B is relevant to theillustration, the arrow may point from element A to element B. Thisunidirectional arrow does not imply that no other information istransmitted from element B to element A. Further, for information sentfrom element A to element B, element B may send requests for, or receiptacknowledgements of, the information to element A.

In this application, including the definitions below, the term ‘module’or the term ‘controller’ may be replaced with the term ‘circuit.’ Theterm ‘module’ may refer to, be part of, or include processor hardware(shared, dedicated, or group) that executes code and memory hardware(shared, dedicated, or group) that stores code executed by the processorhardware.

The module may include one or more interface circuits. In some examples,the interface circuits may include wired or wireless interfaces that areconnected to a local area network (LAN), the Internet, a wide areanetwork (WAN), or combinations thereof. The functionality of any givenmodule of the present disclosure may be distributed among multiplemodules that are connected via interface circuits. For example, multiplemodules may allow load balancing. In a further example, a server (alsoknown as remote, or cloud) module may accomplish some functionality onbehalf of a client module.

The term code, as used above, may include software, firmware, and/ormicrocode, and may refer to programs, routines, functions, classes, datastructures, and/or objects. Shared processor hardware encompasses asingle microprocessor that executes some or all code from multiplemodules. Group processor hardware encompasses a microprocessor that, incombination with additional microprocessors, executes some or all codefrom one or more modules. References to multiple microprocessorsencompass multiple microprocessors on discrete dies, multiplemicroprocessors on a single die, multiple cores of a singlemicroprocessor, multiple threads of a single microprocessor, or acombination of the above.

Shared memory hardware encompasses a single memory device that storessome or all code from multiple modules. Group memory hardwareencompasses a memory device that, in combination with other memorydevices, stores some or all code from one or more modules.

The term memory hardware is a subset of the term computer-readablemedium. The term computer-readable medium, as used herein, does notencompass transitory electrical or electromagnetic signals propagatingthrough a medium (such as on a carrier wave); the term computer-readablemedium is therefore considered tangible and non-transitory. Non-limitingexamples of a non-transitory computer-readable medium are nonvolatilememory devices (such as a flash memory device, an erasable programmableread-only memory device, or a mask read-only memory device), volatilememory devices (such as a static random access memory device or adynamic random access memory device), magnetic storage media (such as ananalog or digital magnetic tape or a hard disk drive), and opticalstorage media (such as a CD, a DVD, or a Blu-ray Disc).

The apparatuses and methods described in this application may bepartially or fully implemented by a special purpose computer created byconfiguring a general purpose computer to execute one or more particularfunctions embodied in computer programs. The functional blocks andflowchart elements described above serve as software specifications,which can be translated into the computer programs by the routine workof a skilled technician or programmer.

The computer programs include processor-executable instructions that arestored on at least one non-transitory computer-readable medium. Thecomputer programs may also include or rely on stored data. The computerprograms may encompass a basic input/output system (BIOS) that interactswith hardware of the special purpose computer, device drivers thatinteract with particular devices of the special purpose computer, one ormore operating systems, user applications, background services,background applications, etc.

The computer programs may include: (i) descriptive text to be parsed,such as HTML (hypertext markup language), XML (extensible markuplanguage), or JSON (ii) assembly code, (iii) object code generated fromsource code by a compiler, (iv) source code for execution by aninterpreter, (v) source code for compilation and execution by ajust-in-time compiler, etc. As examples only, source code may be writtenusing syntax from languages including C, C++, C#, Objective-C, Swift,Haskell, Go, SQL, R, Lisp, Java®, Fortran, Perl, Pascal, Curl, OCaml,Javascript®, HTML5 (Hypertext Markup Language 5th revision), Ada, ASP(Active Server Pages), PHP (PHP: Hypertext Preprocessor), Scala, Eiffel,Smalltalk, Erlang, Ruby, Flash®, Visual Basic®, Lua, MATLAB, SIMULINK,and Python®.

None of the elements recited in the claims are intended to be ameans-plus-function element within the meaning of 35 U.S.C. §112(f)unless an element is expressly recited using the phrase “means for” or,in the case of a method claim, using the phrases “operation for” or“step for.

What is claimed is:
 1. A method of sharing a state of an applicationfrom a first user device to a second user device, the method comprising:receiving at a processor of the first user device a user input to sharethe state of the application, wherein the application is executed on theprocessor at the first user device; in response to the user input,generating a share request and a destination request; selecting a sharemethod and a destination link based on responses to the share requestand the destination request; determining app state informationcorresponding to the state of the application; generating via theprocessor a first data object based on the app state information; andtransmitting the first data object from the processor to a sharingserver or the second user device based on the share method and thedestination link, wherein the transmitting of the first data objectshares the state of the application with the second user device.
 2. Themethod of claim 1, further comprising, while determining the app stateinformation: transmitting a request for a card record or at least aportion of the app state information from the first user device to asharing server; and receiving the card record or the at least a portionof the app state information from the sharing server at the processor.3. The method of claim 2, wherein the card record further comprisesinstructions for accessing an application programming interface (API)via a remote API server in order to obtain additional application stateinformation.
 4. The method of claim 1, further comprising: displaying acard corresponding to the first data object and the state of theapplication on the first user device; determining whether to modify thecard; if the card is to be modified, then at least one of modifying thestate of the application, generating a second share request and a seconddestination request, determining second app state information; andupdating the first data object prior to transmission of the first dataobject to the sharing server or the second user device.
 5. The method ofclaim 1, further comprising: retrieving a portion of card recordinformation from the first data object; sending a request to the sharingserver, wherein the request comprising an application card identifier;and receiving in response to the request, a remaining portion of thecard record information.
 6. A method comprising: receiving a requestfrom a first user device at a processor of a sharing server for a cardrecord or app information, wherein the card record and the appinformation corresponds to a state of an application executed at thefirst user device, and wherein the request comprises an application cardidentifier; accessing card record information for the card record andbased on the application card identifier, wherein the card recordinformation comprises application state information, a templateidentifier, and access information, and wherein the card recordinformation has a reference to the application executed on the firstuser device and indicates an operation for a version of the applicationto enter the state; sending, in response to the request, the card recordinformation to the first user device; receiving a first data objectbased on the card record information; selecting a template based on thetemplate identifier of the card record or the first data object;populating the template with at least part of the application stateinformation from the card record; and at least one of transmitting thetemplate to a second user device, or formatting the first data object togenerate a second data object and transmitting the second data objectfrom the sharing server to a second user device.
 7. The method of claim6, further comprising: receiving the first data object from the seconduser device; formatting the first data object to generate the seconddata object; and transmitting the second data object from the sharingserver to the second user device.
 8. The method of claim 7, furthercomprising: selecting the template based on the second data object; andtransmitting the template from the sharing server to the second userdevice.
 9. The method of claim 6, further comprising: the first dataobject includes an identification of the second user device; determininga compatibility type of the second user device based on theidentification of the second user device; formatting the first dataobject to generate a second data object based on the compatibility type;and transmitting the second data object from the sharing server to thesecond user device, wherein the second data object comprises the cardrecord and the access information, wherein the access information has areference to the application executed on the first user device andindicates an operation for a version of the application to enter thestate, and wherein the access information is formatted based on thecompatibility type of the second user device.
 10. The method of claim 9,wherein determining the compatibility type of the second user devicecomprises searching a data storage device for compatibility informationbased on the identification of the second user device.
 11. The method ofclaim 6, wherein the card record comprises instructions for accessing anapplication programming interface (API) or a remote API server in orderto obtain additional application state information.
 12. The method ofclaim 6, wherein selecting the template comprises: determining whetherany templates correspond to the template identifier; and in response todetermining that no template corresponds to the template identifier,selecting a default template, and otherwise selecting a template thatmatches the template identifier, wherein the default template ispopulated by a subset of the application state information.
 13. Themethod of claim 6, wherein the first data object further comprisesdisplay configuration data that maps the application state informationto one or more fields of the template.
 14. The method of claim 6,further comprising populating the template based on at least one of auser device type of the first user device, an operating system of thefirst user device, a data object type, or a user type.
 15. A method ofrendering app state data, corresponding to an app executed at a firstuser device, at a second user device, the method comprising: receivingat a processor of the second user device, a first data object from thefirst user device, wherein the first data object represents a state ofthe app executed on the first user device, and wherein the first dataobject comprises an application card identifier; determining whether tomodify the first data object; if the first data object is not modified,requesting a first template for the first data object from a sharingserver, displaying, based on information in the first data object andthe first template, the state of the app, a first card corresponding tothe state of the app, or app information corresponding to the state ofthe App; and if the first data object is modified, transmitting thefirst data object to a sharing server, receiving a second data objectfrom the sharing server, wherein the second data object is a formattedversion of the first data object, receiving a second template for thesecond data object from the sharing server, and displaying, based oninformation in the second data object and the second template, a stateof a second version of the app, a second card corresponding to the stateof the second version of the app, or app information corresponding tothe state of the second version of the app.
 16. The method of claim 15,further comprising: receiving a user selection of a user-selectablelink, wherein the first card or the second card comprises theuser-selectable link associated with application access information; andexecuting the app or the second version of the app on the second userdevice based on the selected user selectable link and the applicationaccess information.
 17. The method of claim 15, wherein the determiningof whether to modify the first data object includes determining whetherthe state of the app executed on the first user device is static ordynamic.
 18. The method of claim 15, further comprising generating thefirst card based on the first template or the first data object.
 19. Themethod of claim 15, further comprising generating the second card basedon the second template or the second data object.
 20. The method ofclaim 15, wherein: the first card is, based on access informationprovided in the first template, selectable to cause an applicationexecuted on the second user device to enter the state of the appexecuted on the first user device; and the second card is, based onaccess information provided in the second template, selectable to causethe second version of the app as executed on the second user device toenter a state corresponding to the state of the app executed on thefirst user device.
 21. The method of claim 15, further comprising:retrieving a portion of card record information from the first dataobject; sending a request to the sharing server, the request comprisingthe application card identifier; and receiving in response to therequest, a remaining portion of the card record information.